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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041228072103.GH15591>