From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 13:45:14 2012 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 9BF81106566C; Fri, 6 Jan 2012 13:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF388FC13; Fri, 6 Jan 2012 13:45:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 24C0F46B2D; Fri, 6 Jan 2012 08:45:14 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A8C59B941; Fri, 6 Jan 2012 08:45:13 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 6 Jan 2012 08:40:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201060840.04156.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 06 Jan 2012 08:45:13 -0500 (EST) Cc: Robert Watson , Navdeep Parhar Subject: Re: tcp_detach can return with inpcb lock held 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: Fri, 06 Jan 2012 13:45:14 -0000 On Friday, January 06, 2012 6:22:25 am Robert Watson wrote: > > On Thu, 5 Jan 2012, Navdeep Parhar wrote: > > > Looks like there's a case where tcp_detach could return with the inp lock > > held. I see an XXXRW comment questioning this possibility, but we should > > either add an assertion to verify that the case does not occur, or unlock > > the inpcb before returning. Or maybe both? > > Hi Navdeep: > > A number of other folks have pointed this out as well -- usually while > tracking a different bug, so a fix never gets committed. I believe we should > commit + merge the patch you've proposed. However, as far as I'm aware, it's > never triggered, so the comment is probably correct. I'm not sure if we want > to make the comment an invariant, since other than avoiding this bug, it > shouldn't need to be true (I think). If you really think it shouldn't occur, then commit the patch below and MFC it to stable branches, but change the code in HEAD afterwards to add the assertion. Then you will eventually find out if it's wrong (hopefully) as I did with the assertions I added to tcp_input() for rcv_nxt and rcv_adv. :) -- John Baldwin