From owner-svn-src-head@FreeBSD.ORG Wed May 15 05:25:07 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF9A295; Wed, 15 May 2013 05:25:07 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1BFECBFD; Wed, 15 May 2013 05:25:07 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id 40B8B71A710; Wed, 15 May 2013 09:25:01 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 09:09:33 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 23:11:08 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 20:58:27 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id D259671A914 for ; Mon, 13 May 2013 20:58:27 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0CSxk1pdU2b for ; Mon, 13 May 2013 20:58:20 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-svn-src-all@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-svn-src-all@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id 3C71271A9D6 for ; Mon, 13 May 2013 20:58:20 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 482701F7A; Mon, 13 May 2013 16:58:17 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id 4609D704; Mon, 13 May 2013 16:58:17 +0000 (UTC) (envelope-from owner-svn-src-all@freebsd.org) Delivered-To: svn-src-all@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 41212597 for ; Mon, 13 May 2013 16:58:05 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 135398FC for ; Mon, 13 May 2013 16:58:05 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 16so13039941iea.3 for ; Mon, 13 May 2013 09:58:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=j/euV2TD5CtvzDWR4664HMqKmfZ2ytMuVPpg9CN7+U8=; b=jyDVeyu8GmzaackMqLJB0g5CVOeInYhA/PnpDXQzsIjSQbQTp/s3KRiDtHinCPQIKz RYKpe5FceeWFN+Cr1MF+tEZAkVXgVz696x/ucXaGoSbwsXjpbGX2roXYHgjS9FV+Db+C izUWbHlKyXWSkgQfbKpr/tZ3qHVv1/ylmXjr6nFqhBxLAIu3Pzok4iKwmJC3iEoMMGEB q7/2AgOMkELAqIR9WudqIUxgQhVTIis5Sg3dR4viKdbLIUweptsTtcwvMD/F4xPEVEMK MCr/Zu3XQA/ZLjgz5DOlTVkkO5s/riMCS/SjA9RfzuDGaTbyiQkS6d/fgeSLREzQ87WZ CuDg== MIME-Version: 1.0 X-Received: by 10.50.103.102 with SMTP id fv6mr10528310igb.6.1368464284683; Mon, 13 May 2013 09:58:04 -0700 (PDT) Received: by 10.231.49.74 with HTTP; Mon, 13 May 2013 09:58:04 -0700 (PDT) In-Reply-To: <518F320D.3070304@mu.org> References: <201305091628.r49GSI33039873@svn.freebsd.org> <518F320D.3070304@mu.org> Date: Mon, 13 May 2013 10:58:04 -0600 Message-ID: Subject: Re: svn commit: r250411 - in head/sys: conf kern sys From: Will Andrews To: Alfred Perlstein X-Gm-Message-State: ALoCoQkp8pRlHxLiuWu9r4FjOUNdSXLFx0wMW0w861syjoVt72QQItTXzQQkV6DVkEBnjyEoj5/4 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-svn-src-all@freebsd.org Sender: owner-svn-src-all@freebsd.org X-OriginalArrivalTime: 13 May 2013 16:58:27.0938 (UTC) FILETIME=[16DE5C20:01CE4FFB] Cc: Marcel Moolenaar , jhb@freebsd.org, svn-src-all@freebsd.org, alfred@freebsd.org, attilio@freebsd.org, src-committers@freebsd.org, Jeff Roberson , svn-src-head@freebsd.org X-BeenThere: svn-src-head@freebsd.org 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: Wed, 15 May 2013 05:25:07 -0000 On Sun, May 12, 2013 at 12:09 AM, Alfred Perlstein wrote: > Can we just admit to ourselves that tweaks to debugging macros/printing > and WITNESS are our kernel developer's "bikeshed zone" and get over the > fact that people's needs may diverge and changing non-default behavior in > non-critical paths is not going to be the death of the kernel as we know it? > > I could certainly believe that this sort of thing needs long and thorough > discussion if it wasn't the equivalent of style tweaks to manpages. > > Let's leave the long and lengthy discussions to things that matter such as > standards compliance, ABI, API and really cool performance and stability > stuff. Except that this is *not* the equivalent of style tweaks. I'm not sure how you got that from Jeff's email. False positive LORs results in people ignoring all LORs, including real ones. And that impacts stability. Especially if you are trying to implement performance improvements or fix bugs; in that case, the LORs act as a safeguard against violating existing object relationship assumptions. Having worked on ZFS for a while, I can say that many (if not most) of the LORs reported there that are false positives are because the locks represent objects that are frequently and legitimately related to each other in reverse orders, due to reuse of object types at different points in the overall hierarchy. So, I agree that the biggest issue is that witness's model of comparing strings is insufficient for representing more complex lock relationships. In ZFS, in most cases, the locks are acquired after having already (in debug builds) checked these relationships. It seems appropriate, therefore, that witness should be improved by adding the ability to bless specific object relationships on a per-lock entry basis, so that we continue to be notified about *legitimate* LORs, at every call site and between every pair of object types. It also seems best to add a new API for this purpose, so that it can be used regardless of which lock type is being used, without having to modify all existing lock calls. This does mean that code in FreeBSD would need to independently verify the object relationships, but doing so is, IMHO, a lot easier to improve upon than folding this functionality into existing APIs by adding more arguments. --Will. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"