From owner-svn-src-head@FreeBSD.ORG Fri May 10 20:02:33 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5624E419; Fri, 10 May 2013 20:02:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2755F3EE; Fri, 10 May 2013 20:02:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C1572B926; Fri, 10 May 2013 16:02:28 -0400 (EDT) From: John Baldwin To: Marcel Moolenaar Subject: Re: svn commit: r250411 - in head/sys: conf kern sys Date: Fri, 10 May 2013 15:33:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305091628.r49GSI33039873@svn.freebsd.org> <201305101211.35808.jhb@freebsd.org> <6CBEB766-087B-41F4-B549-2D60F4FD2701@xcllnt.net> In-Reply-To: <6CBEB766-087B-41F4-B549-2D60F4FD2701@xcllnt.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305101533.26992.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 10 May 2013 16:02:28 -0400 (EDT) Cc: attilio@freebsd.org, svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar , src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:02:33 -0000 On Friday, May 10, 2013 2:51:20 pm Marcel Moolenaar wrote: > > On May 10, 2013, at 9:11 AM, John Baldwin wrote: > > > On Friday, May 10, 2013 11:46:54 am Marcel Moolenaar wrote: > >>> > >>> 2) vnode locks from a local filesystem that report a LOR with a "devfs" > >>> vnode. Typical reports are either "ufs" -> "devfs" or in some cases > >>> "ufs" -> "devfs" -> "ufs". As with 1), I would much rather tag the > >>> offending location than to disable all WITNESS checking on vnode locks. > >> > >> With more file system types in use, this will get mixed up with the > >> other file systems and noise you get is rather severe. It is a big > >> problem for us at Juniper. > > > > Note, it is very specific that the second lock is always "devfs". I think > > that points to this being isolated to a few specific places, not a generic > > ordering problem. > > Alas, that's not the case. These LORs are reported between ufs and unionfs, > or ufs and isofs, etc. It's not just between something and devfs. Ugh, I have only seen them with devfs so had presumed them to be more localized (and thus more easily targeted). In that case your change may be as fine-grained as we can get. I would also like to still keep WITNESS checking between vnode locks and other lock types, and LK_NOWITNESS would remove that, so between your change and Attilio's approach I do prefer yours. > I'm not sure the only options we have are to ignore the problem > or implement a general fix. If we set out to silence witness for > the known false positives then it's ok to handle them on a case > by case basis. We'll see patterns soon enough and then re-code > the solutions in terms of those patterns. If we're lucky we see > a single general solution, but if not, then it's fine to have a > handful of special case. The worse we can do is not address it > at all. I was assuming that the reversals were far more specific, and knowing about other false positives like the dirhash one, I want a generic way to do more fine-grained marking of false positives. If there were only a few places we would need to mark to fix the reversals you see, then I would prefer the suspend/resume approach for your case. However, the reversals you are masking sound too widespread to support that. -- John Baldwin