Old LOR between devfs & devfsmount resurfacing?

[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?

-- 
Marcel Moolenaar
xcllnt at mac.com