From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 19:28:41 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 B2C6516A41B; Thu, 7 Feb 2008 19:28:41 +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 8FE2B13C46A; Thu, 7 Feb 2008 19:28:41 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout009/MantshX 4.0) with ESMTP id m17JSfrZ015899; Thu, 7 Feb 2008 11:28:41 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id m17JSbNt016770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2008 11:28:38 -0800 (PST) Message-Id: <3150AF40-205F-4424-814F-6A9305E698E7@mac.com> From: Marcel Moolenaar To: Attilio Rao In-Reply-To: <3bbf2fe10802071041j6d2748f9n16c28541da1e0430@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 11:28:36 -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> <4CB73483-B3BB-4819-B3B5-5F349D16C6F7@mac.com> <3bbf2fe10802071041j6d2748f9n16c28541da1e0430@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 19:28:41 -0000 On Feb 7, 2008, at 10:41 AM, Attilio Rao wrote: > 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. Where you see pollution, I see opportunity. In principle no code should have to use these region markers, so in the few cases it's needed it not only stands out, but also allows any sized region, possibly covering multiple functions to be marked. That's much less pollution and/or change than having to tag each and every lock operation. On top of that, it can be used for debugging purposes where any lock operation within the region triggers a particular action, such as printing of backtraces or tracing held locks. This allows developers to get visibility in the contexts in which the lock operations are being performed. In any case: it was merely a thought, one that apparently didn't spark any new thoughts for you... -- Marcel Moolenaar xcllnt@mac.com