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

[Alan Cox]

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