Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Dec 2004 14:48:46 -0600
From:      Alan Cox <alc@cs.rice.edu>
To:        Darren Reed <darrenr@hub.freebsd.org>
Cc:        "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: cvs commit: src/sys/contrib/ipfilter/netinet ip_auth.c
Message-ID:  <20041227204846.GC15591@noel.cs.rice.edu>
In-Reply-To: <20041227054931.GC20920@hub.freebsd.org>
References:  <20041226165927.GA18879@hub.freebsd.org> <Pine.BSF.4.53.0412261707210.68472@e0-0.zab2.int.zabbadoz.net> <20041226182537.GB20920@hub.freebsd.org> <20041226.222435.52824948.imp@bsdimp.com> <20041227054931.GC20920@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@hub.freebsd.org>
> >             Darren Reed <darrenr@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041227204846.GC15591>