Re: Lock order reversal .

On 12/7/10 3:41 AM, Attilio Rao wrote:
> 2010/12/7 Erik Cederstrand<erik_at_cederstrand.dk>:
>> Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:
>>
>>> On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk<m.e.sanliturk_at_gmail.com>  wrote:
>>>
>>>> A Dmesg.TXT is attached having a lock order reversal .
>>>     The mount LOR is well known.
>> I see that this is the standard response to lot's of LOR reports. It seems to be one of the most-reported errors on CURRENT (and it's certainly a loud one), but I think a lot of people waste time researching the error and browsing Bjoerns LOR page, only to get the above response (not picking on you, Garrett).
>>
>> Do we have the possibility of silencing well-known and presumably harmless LOR's if there isn't sufficient motivation to fix the source?
> Witness has an 'internal blessing list' we never wanted to use in
> order to keep them popping up as reminder.
> Actually, the fact the LOR is 'known' doesn't mean it is 'analyzed'.
> The very few 'Analyzed but harmless' cases in the past have been
> handled via _NOWITNESS flags I guess.

the problem is that the witness output tells you the second case (the 
reversed case)
but it doesn't have any clues about the first case (the one that wsa 
the other way around).

An extended witness might use a lot of memory but associate with each 
lock a 'last place called when a lock was already held'
that might give a clue as to where the other instance was. I'm not 
volunteering to write it,
but it might be very worth while.. I'd certainly like to hear other 
ideas as well.


> Attilio
>
>