cvs commit: src/sys/contrib/ipfilter/netinet ip_auth.c

Alan Cox alc at
Mon Dec 27 23:21:30 PST 2004

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.
> 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


More information about the cvs-all mailing list