From owner-cvs-all@FreeBSD.ORG Tue Dec 28 05:18:38 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id C5A3216A4CF; Tue, 28 Dec 2004 05:18:38 +0000 (GMT) Date: Tue, 28 Dec 2004 05:18:38 +0000 From: Darren Reed To: Scott Long Message-ID: <20041228051838.GB38011@hub.freebsd.org> References: <20041226165927.GA18879@hub.freebsd.org> <20041226182537.GB20920@hub.freebsd.org> <20041226.222435.52824948.imp@bsdimp.com> <20041227054931.GC20920@hub.freebsd.org> <20041227204846.GC15591@noel.cs.rice.edu> <20041228031707.GA38011@hub.freebsd.org> <41D0D580.7090207@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41D0D580.7090207@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: src-committers@freebsd.org cc: cvs-src@freebsd.org cc: Alan Cox cc: cvs-all@freebsd.org cc: darrenr@freebsd.org cc: bzeeb-lists@lists.zabbadoz.net cc: "M. Warner Losh" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 05:18:38 -0000 On Mon, Dec 27, 2004 at 08:39:44PM -0700, Scott Long wrote: > The locking APIs have existed in FreeBSD 5.x for 4 years. They are > documented in manual pages, web pages, and publically available USENIX > papers. Just because you don't agree that sx locks should be sleepable > doesn't mean that your opinion is valid. Hmmm, maybe I'm not communicating my view properly. I'm not fussed about whether or not sx locks are sleepable. What's wrong, IMHO, is the witness code and the implication that acquiring a sleepable lock, while you have a mutex, is wrong. Or vice versa. So long as the order is always the same, it should not present a problem if the programmer is careful. Even "debug" kernels on Solaris don't have restrictions like that between mutex/rw-locks, although Solaris never allows you to do a recursive mutex, like FreeBSD. FWIW, John Baldwin's USENIX paper that talks about witness from BSDi only talks about it in context of locking order: http://www.usenix.org/events/bsdcon02/full_papers/baldwin/baldwin_html/node7.html#SECTION00072000000000000000 The problem it is complaining about w.r.t ipfilter is not what the paper talks about here. As it is, if I were to refer to: http://sources.zabbadoz.net/freebsd/lor.html 050 - i've actually changed the code for other reasons so it should not happen at some point in the future 051 - why is UDP holding on to the lock for so long ? this doesn't look like an ipfilter problem. 052 - i'm dumbfounded. IFNET_RLOCK uses mtx, not sx. 052 is a classic case of why this LOR report is not useful. The witness code is complaining because a mutex is being acquired while a sleepable lock is held, for the purpose of walking a linked list. I mean WTF? Just to reiterate, it's the witness code and the semantics it is trying to enforce (which are somewhat different, now?) that I have an issue with, not the lock implementations. Darren