From owner-freebsd-net@FreeBSD.ORG Tue Jul 31 18:24:34 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7869B16A41A for ; Tue, 31 Jul 2007 18:24:34 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id A9E4913C442 for ; Tue, 31 Jul 2007 18:24:32 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 72FFCBC93; Tue, 31 Jul 2007 14:24:29 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 31 Jul 2007 14:24:30 -0400 X-Sasl-enc: rGKN61a6Dd43Oojs3BnFAoZidjhm/zxF47O5M/zLDKYC 1185906269 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2E54A50BF; Tue, 31 Jul 2007 14:24:29 -0400 (EDT) Message-ID: <46AF7E57.5020209@incunabulum.net> Date: Tue, 31 Jul 2007 19:24:23 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20070731162515.GA3684@sub> In-Reply-To: <20070731162515.GA3684@sub> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, rwatson@freebsd.org Subject: Re: divert and deadlock issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 18:24:34 -0000 Christian S.J. Peron wrote: > ... > One idea was to duplicate the socket options mbuf and pass in a NULL pointer > for the multi-cast options. Keep in mind that these are multicast options > associated with a divert socket. > > So I guess the questions: > > (1) Are there any users that are specifying multicast options on divert sockets? > (2) Are there any users that are specifying socket options in general for > divert sockets? > The LOR is obviously being triggered by ip_output()'s acquisition of in_multi_mtx, due to a datagram being sent to a multicast destination and a subsequent lookup being required. I can't think of a reason why a user would wish to supply any multicast socket options to a divert socket, other than the 'small' ones, i.e. IP_MULTICAST_TTL/IF/LOOP/VIF. See the comments about idempotence inside in_mcast.c on the HEAD branch, about why you can't just wish them away. It seems reasonable that this subset of the multicast options are supported for divert sockets given the likely use cases, even if IPPROTO_DIVERT supports IP_HDRINCL, because IP_MULTICAST_TTL does not do what you think it does (see in_mcast.c comments again). Joining groups on a divert socket SHOULD NOT be supported (it does not make sense semantically) and we should deliberately return EINVAL for multicast options other than the above subset. Dropping the inpcb lock over ip_output() looks like the easy option. Alternatively, we could just not support multicast options on divert sockets given that it is a rare use case as per above. BMS