From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 18:41:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F06416A418 for ; Thu, 7 Feb 2008 18:41:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id BAD4613C50C for ; Thu, 7 Feb 2008 18:41:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2864354fgg.35 for ; Thu, 07 Feb 2008 10:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Yf5jPtPyzTwINKHRBhMEY9Fc0JCoavekHogjGMt/1R0=; b=Tyru3yP0vLOZ4JUlbYYbRmFS9hLbHQ/mwZXFZbU+nLXsiZRFhu3R57tthyopEN9VEVnWbfKpLVybaD57R0lTZhrqm7zYzkzAG0ashtV1ICqmjbB6ip4lx6yHukVCheTkJq7WjvSwoJMUcUJC8DfgHW2Gp4/61clkcmfLRiC/wrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pHI3NjmH3/K27bQgYpyMX37TI4f6d9DACsVFxpgkwAUR133hxzbC6jAhT0UU82bc4VrGOgZ58vOhN4fjnWbWLUAL5m+UE97pGU6mX54BDM9WdpvEd+zOWd8vW6R4EyHek/rWtbf0+R36tGSnFkmI1jOlA5CLsEIv/9HhzX9c6XU= Received: by 10.86.79.19 with SMTP id c19mr10731370fgb.31.1202409704112; Thu, 07 Feb 2008 10:41:44 -0800 (PST) Received: by 10.86.28.19 with HTTP; Thu, 7 Feb 2008 10:41:44 -0800 (PST) Message-ID: <3bbf2fe10802071041j6d2748f9n16c28541da1e0430@mail.gmail.com> Date: Thu, 7 Feb 2008 19:41:44 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Marcel Moolenaar" In-Reply-To: <4CB73483-B3BB-4819-B3B5-5F349D16C6F7@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080207045015.GW57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070216idd5206ey7a66c0873311e66c@mail.gmail.com> <20080207104354.GY57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070304r29cb8d2u1210fe285c917424@mail.gmail.com> <20080207110901.GZ57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070421m3a3152a3m6c9aa67d649107e4@mail.gmail.com> <20080207125252.GC57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070611v6c7714b5y18bef10d586944c4@mail.gmail.com> <4CB73483-B3BB-4819-B3B5-5F349D16C6F7@mac.com> X-Google-Sender-Auth: c45ce7450123859a Cc: Kostik Belousov , current@freebsd.org Subject: Re: Old LOR between devfs & devfsmount resurfacing? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2008 18:41:46 -0000 2008/2/7, Marcel Moolenaar : > On Feb 7, 2008, at 6:11 AM, Attilio Rao wrote: > > >>>>>>>> Correct lock order is devfs vnode -> devfs mount sx lock. When > >>>>>>>> allocating new devfs vnode, see devfs_allocv(), the newly > >>>>>>>> created > >>>>>>>> vnode is locked while devfs mount lock already held (see line > >>>>>>>> 250 of > >>>>>>>> fs/devfs/devfs_vnops.c). Nonetheless, this cannot cause > >>>>>>>> deadlock since > >>>>>>>> no other thread can find the new vnode, and thus perform the > >>>>>>>> other lock > >>>>>>>> order for this vnode lock. > >>>>>>>> > >>>>>>>> The fix is to shut the witness in this particular case. > >>>>>>>> Attilio, how to > >>>>>>>> do this ? > >>>>>>> > >>>>>>> Just add LK_NOWITNESS for one of the lock involved in the > >>>>>>> lockinit(). > >>>>>> > >>>>>> > >>>>>> Then, we loss the useful reports of the actual LORs later, > >>>>>> isn't it ? > >>>>> > >>>>> Another solution would be to rewamp BLESSING option which allow to > >>>>> 'bless' some LORs. > >>>>> jhb and me, btw, didn't want to enable it because it could lead > >>>>> some > >>>>> less experienced developer to hide LORs under this label and > >>>>> this is > >>>>> something we want to avoid. > >>>> > >>>> > >>>> This LOR shall not be ignored globally. When real, it caused the > >>>> easily > >>>> reproducable lockup of the machine. > >>>> > >>>> It would be better to introduce some lockmgr flag to ignore > >>>> _this_ locking. > >>> > >>> flag to pass where? > >> To the lockmgr itself at the point of aquisition, like > >> lockmgr(&lk, LK_EXCLUSIVE | LK_INTERLOCK | LK_NOWARN, > >> &interlk, ...); > > > > No, I really want a general WITNESS support for this (as I also think > > that having something more fine grained than BLESSING will break all > > concerns jhb and me are considering now). > > A simple way to do it would mean hard-coding file and line in a > > witness table. While file is ok, line makes trouble so we should find > > an alternative way to do this. Otherwise we can consider skiping > > checks for a whole function, this should be not so difficult to > > achive. > > > > I need to think more about this. > > > What about a linker set that lists file regions (based on line number). > If you want to exclude a particular lock from WITNESS you can do > something like this: > WITNESS_REGION_START(function) > lockmgr(...) > WITNESS_REGION_END > > The WITNESS_REGION_START and WITNESS_WITNESS_END together create a > region in the linker set and witness can check if a lock operation > falls within that region. If yes, we can make it do something special > by given the _START and/or _END a function pointer or we can make it > ignore the operation by passing NULL or something. > > You can safely use file & line numbers in this case. Something along > those lines... > > Thoughts? Really, if I wanted to pollute consumers code I would have use a lot of simpler ideas. I'd like strongly to maintain WITNESS_* namespace usage only in locking primitives. Attilio -- Peace can only be achieved by understanding - A. Einstein