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

From: Alan Cox <>
Date: Mon, 27 Dec 2004 14:48:46 -0600
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: <>
> >             Darren Reed <> writes:
> > : On Sun, Dec 26, 2004 at 05:09:23PM +0000, Bjoern A. Zeeb wrote:
> > : > [1]
> > : 
> > : 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.


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.

Received on Mon Dec 27 2004 - 20:49:06 UTC