Re: cvs commit: src/sys/contrib/ipfilter/netinet ip_auth.c
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:
> > : >  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.
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