From owner-svn-src-all@FreeBSD.ORG Sat May 11 14:34:50 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDE2FD69; Sat, 11 May 2013 14:34:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 7A75FAE8; Sat, 11 May 2013 14:34:50 +0000 (UTC) Received: by mail-ia0-f177.google.com with SMTP id z3so2954236iad.22 for ; Sat, 11 May 2013 07:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jjnUH/JB0EdRHxlbRZrYZbc17BAEodUoVLNMvJhE0Bg=; b=XjrKTWuhyFl/qEQG1NZE0mhZkHs/g6/zS3f49irIMbLtZ6gR327M/1UADzIavcSSEp z8jKAGkLfzrxuy3imQkIm1ToofeCIA/CwXfcNJg0iZyy0tlSFv17Bpipo575H0qj8lmN 0cPW2oMAadYG3I3WLebLFyYBJeaqQT+IV2aVv7eb9WRo7yt9UPOPSQrbqnL1kJfz0Uyn E4iVheyWXdPxN6sXcT1xYjYEKzzw0a6af6ULMWBQ1Rqn2ougzkWAXecgVxjy7LYAuaAd TNLJuTE8oBqBqhlNZAYyJgNcA00UfjOd8jFCd6HaiZF8fF9Av8vc+24PHk2wS5iI3xpe 438g== MIME-Version: 1.0 X-Received: by 10.43.138.196 with SMTP id it4mr365819icc.3.1368282890152; Sat, 11 May 2013 07:34:50 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.117.134 with HTTP; Sat, 11 May 2013 07:34:50 -0700 (PDT) In-Reply-To: <201305101533.26992.jhb@freebsd.org> References: <201305091628.r49GSI33039873@svn.freebsd.org> <201305101211.35808.jhb@freebsd.org> <6CBEB766-087B-41F4-B549-2D60F4FD2701@xcllnt.net> <201305101533.26992.jhb@freebsd.org> Date: Sat, 11 May 2013 16:34:50 +0200 X-Google-Sender-Auth: A71mmGbiYm6IQlZ3fU2Vg6G6rP8 Message-ID: Subject: Re: svn commit: r250411 - in head/sys: conf kern sys From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar , src-committers@freebsd.org, Marcel Moolenaar X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 14:34:50 -0000 On Fri, May 10, 2013 at 9:33 PM, John Baldwin wrote: > 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. The solution to this is what I proposed: pass down a LK_NOWITNESS for instances where you don't want to check for witness. This is per lock-call. You localize the fix to the instance you want to shut down and you skip witness for every false-positive. When you commit the LK_NOWITNESS you mention explicitely the reason why the reported LOR is a false positive so it is also documented on svn. I still don't understand what you are objecting. Marcel objections' were completely no-sense (Don't want to involve Witness) but at least I expect some decent one by you. Attilio -- Peace can only be achieved by understanding - A. Einstein