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

[Alan Cox]

On Mon, Dec 27, 2004 at 05:49:31AM +0000, Darren Reed wrote:
> On Sun, Dec 26, 2004 at 10:24:35PM -0700, M. Warner Losh wrote:
> > In message: <20041226182537.GB20920 at hub.freebsd.org>
> >             Darren Reed <darrenr at hub.freebsd.org> writes:
> > : On Sun, Dec 26, 2004 at 05:09:23PM +0000, Bjoern A. Zeeb wrote:
> > : > [1] http://sources.zabbadoz.net/freebsd/lor.html#050
> > : 
> > : This would appear, to me, as deficencies in the witness code
> > : and that perhaps LORs, unless they are in the leadup to a system
> > : deadlock'ing, are just something to be ignored.
> > 
> > Nearly all LORs could lead to system deadlock, especially in low
> > resource situations.  It is highly doubtful that there's a problem in
> > witness.  You should fix your code and not ignore the warning.
> 
> As you say, "Nearly all", not "all".  I believe the IPFilter ones fall
> outside of the "all" group.
> 
> Given what I have seen the witness code do with LOR checking, it is
> trivial to write code that generates a LOR warning without ever being
> vulnerable to causing a system deadlock through resource problems.
> 
> I believe the person who developed witness realised this in time and
> hence added the "blessed" option so tha twarnings would not be emitted
> for specific known safe cases.

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.  That is
not allowed.  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.

Alan