On 12/7/10 3:41 AM, Attilio Rao wrote:
2010/12/7 Erik Cederstrand<e...@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.sanlit...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
