From owner-svn-src-head@FreeBSD.ORG Sat May 11 14:31:41 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 5F62DAF6; Sat, 11 May 2013 14:31:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 13CDAAD2; Sat, 11 May 2013 14:31:40 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id e11so9888182iej.30 for ; Sat, 11 May 2013 07:31:39 -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=O0EvQuEncgUsvICj/5YYeTvFPZzwvpMruD9I3z+OjO4=; b=Zc5ZW/GGGSIzh8nWpVEfDHTDrfvcDQgnVibzYwhKbVny2EzLuQJAHhdm38E54IQpPI l7lDj6uJUAh6PDQCF5uWlvuND1Drp7XFBmkoMhGLWwGqCpThWNQwmnRjBV2j5bKc+Kac qZ2ENunlWaVBRTBTONTkZKQ0NepqbHPPryvmjw2aJentlVdWBbKpMsead3s2ZKXX8q+K zXLd/5Vvn/sEAsPAmp0DuA2HBIQc4/Do8yACWvzZMBRoplHxpuFIM7ALFjuH6kcRKJ/I f4kbrrJpyUDRGcjyxqqswCo1Z+BVW1jokpyZR6M/0MoSCLDRYp8dLBun1w3Dh7oSCtVu 6jNA== MIME-Version: 1.0 X-Received: by 10.50.7.36 with SMTP id g4mr5312100iga.64.1368282699064; Sat, 11 May 2013 07:31:39 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.117.134 with HTTP; Sat, 11 May 2013 07:31:38 -0700 (PDT) In-Reply-To: <201305100952.45101.jhb@freebsd.org> References: <201305091628.r49GSI33039873@svn.freebsd.org> <201305100952.45101.jhb@freebsd.org> Date: Sat, 11 May 2013 16:31:38 +0200 X-Google-Sender-Auth: nYgbHWWl8Xa4Nxf-IbZiV3bKMRQ 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-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@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: Sat, 11 May 2013 14:31:41 -0000 On Fri, May 10, 2013 at 3:52 PM, John Baldwin wrote: > On Thursday, May 09, 2013 4:56:33 pm Marcel Moolenaar wrote: >> >> On May 9, 2013, at 9:46 AM, Attilio Rao wrote: >> >> > On Thu, May 9, 2013 at 6:28 PM, Marcel Moolenaar > wrote: >> >> Author: marcel >> >> Date: Thu May 9 16:28:18 2013 >> >> New Revision: 250411 >> >> URL: http://svnweb.freebsd.org/changeset/base/250411 >> >> >> >> Log: >> >> Add option WITNESS_NO_VNODE to suppress printing LORs between VNODE >> >> locks. To support this, VNODE locks are created with the LK_IS_VNODE >> >> flag. This flag is propagated down using the LO_IS_VNODE flag. >> >> >> >> Note that WITNESS still records the LOR. Only the printing and the >> >> optional entering into the kernel debugger is bypassed with the >> >> WITNESS_NO_VNODE option. >> > >> > This is the wrong way to deal with such problem and I avoided to do >> > something like that on purpose. >> >> I disagree. We have known LOR messages between VNODE locks that >> pollute the console and so far we haven't fixed the root cause >> in some form or shape. Silencing this known case is good to >> maximize the attention LORs need to be given while still have >> witness involved to catch locking problems with vnodes that are >> of a different nature. >> >> > >> > The way to fix this is to implement LK_NOWITNESS on a per-lock basis >> > into lockmgr, propagate the same concept to the vn_lock() (which >> > should be basically done automatically) and finally identify the >> > false-positive case and commit for them explicitely LK_NOWITNESS on a >> > per-call basis, explaining in detail why the single case reported is a >> > false-positive. >> >> This is worse. You want witness involved. > > Well, I disagree with both of you a bit. I mostly agree with Attilio in > that the committed change is a really large sledgehammer. If we want to > ignore all LORs for a large number of locks in the system we might as well > remove WITNESS altogether. However, I think LK_NOWITNESS is also too large > of a sledgehammer for this as well. AFAIK there are two vnode-related LORs > that I can think of: At this point I think that my e-mail is completely ambiguous because what I'm proposing is the same way we shut down specific LOR with mutexes using mtx_lock_flags(). I don't really understand what are you objecting about. Attilio -- Peace can only be achieved by understanding - A. Einstein