Date: Tue, 28 Dec 2004 01:21:03 -0600 From: Alan Cox <alc@cs.rice.edu> To: Darren Reed <darrenr@hub.freebsd.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/contrib/ipfilter/netinet ip_auth.c Message-ID: <20041228072103.GH15591@noel.cs.rice.edu> In-Reply-To: <20041228031707.GA38011@hub.freebsd.org> References: <20041226165927.GA18879@hub.freebsd.org> <Pine.BSF.4.53.0412261707210.68472@e0-0.zab2.int.zabbadoz.net> <20041226182537.GB20920@hub.freebsd.org> <20041226.222435.52824948.imp@bsdimp.com> <20041227054931.GC20920@hub.freebsd.org> <20041227204846.GC15591@noel.cs.rice.edu> <20041228031707.GA38011@hub.freebsd.org>
index | next in thread | previous in thread | raw e-mail
On Tue, Dec 28, 2004 at 03:17:07AM +0000, Darren Reed wrote: > On Mon, Dec 27, 2004 at 02:48:46PM -0600, Alan Cox wrote: > > Darren, > > > > Based upon a quick look at the above URL, I would say that the problem > > is that you are acquiring an sx lock after a mutex is held. > > Yes, that is what I thought the problem was too. > > > That is not allowed. > > Well, it should be. > [snip] > > What can I say that I haven't already ? > This is a nonsense rule and I'm quite happy that it isn't enforced at > all. The assumption by someone that all of these scenarios lead to > deadlocks is false. Deadlock is not the issue. The implementations of mutex and sx locks don't support the acquisition of mutexes before sx locks. Roughly speaking, when a thread is blocked during the acquisition of a held sx lock, it blocks in a manner similar to tsleep(). For the same reasons that you can't hold a mutex across a tsleep(), you can't hold a mutex when acquiring an sx lock. Yes, it would be nice to have a variant of sx locks that didn't have this restriction, but that is not what we have today. Witness is simply enforcing the restrictions imposed by the existing implementation. Alanhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041228072103.GH15591>