From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 17:42:35 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 4DF0E16A41A; Thu, 7 Feb 2008 17:42:35 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF1C13C474; Thu, 7 Feb 2008 17:42:35 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout009/MantshX 4.0) with ESMTP id m17HHb7d007474; Thu, 7 Feb 2008 09:17:37 -0800 (PST) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id m17HHTTW020549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2008 09:17:30 -0800 (PST) Message-Id: <4CB73483-B3BB-4819-B3B5-5F349D16C6F7@mac.com> From: Marcel Moolenaar To: Attilio Rao In-Reply-To: <3bbf2fe10802070611v6c7714b5y18bef10d586944c4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 7 Feb 2008 09:16:57 -0800 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> X-Mailer: Apple Mail (2.915) 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 17:42:35 -0000 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? -- Marcel Moolenaar xcllnt@mac.com