From owner-cvs-all@FreeBSD.ORG  Mon Dec 27 05:49:31 2004
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 680)
	id 58BEC16A4CF; Mon, 27 Dec 2004 05:49:31 +0000 (GMT)
Date: Mon, 27 Dec 2004 05:49:31 +0000
From: Darren Reed <darrenr@hub.freebsd.org>
To: "M. Warner Losh" <imp@bsdimp.com>
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041226.222435.52824948.imp@bsdimp.com>
User-Agent: Mutt/1.4.2.1i
cc: src-committers@freebsd.org
cc: cvs-src@freebsd.org
cc: scottl@freebsd.org
cc: cvs-all@freebsd.org
cc: darrenr@freebsd.org
cc: bzeeb-lists@lists.zabbadoz.net
Subject: Re: cvs commit: src/sys/contrib/ipfilter/netinet ip_auth.c
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Dec 2004 05:49:31 -0000

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