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

[Scott Long]

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.
> 
> 
>>More generally, an sx lock is termed a "sleepable" lock
>>and a mutex is not; all desired sleepable locks must be acquired
>>before any non-sleepable locks are acquired.  Witness enforces this
>>prohibition, but perhaps causes confusion by calling it a reversal.
> 
> 
> 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.
> 
> I imagine it is part of why things like the IFNET_*LOCK macros use mtx
> rather than sx.  On systems where the interface list is of non-trivial
> size, I imagine this would have a measurable impact.
> 
> Perhaps the most stupid realisation from this has been that IPFilter
> code gets called with a UDP mutex of some sort held.  Like WTF ?
> 
> Darren

The locking APIs have existed in FreeBSD 5.x for 4 years.  They are 
documented in manual pages, web pages, and publically available USENIX
papers.  Just because you don't agree that sx locks should be sleepable
doesn't mean that your opinion is valid.  Also, there is already another
network filter package that is locked, locked correctly, and performs
well.  You are not treading into new waters here.  We can debate the
observation that you hold that there is a UDP lock held, but calling it 
outright stupid doesn't help your case.

Scott