Date: Tue, 7 Dec 2010 11:40:41 -0800 From: Matthew Fleming <mdf356@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, Garrett Cooper <yanegomi@gmail.com>, freebsd-current <freebsd-current@freebsd.org>, Erik Cederstrand <erik@cederstrand.dk> Subject: Re: Lock order reversal . Message-ID: <AANLkTikW4S1mf4%2BcyHV2PqSaYP14pxUYZzjaeho4a62v@mail.gmail.com> In-Reply-To: <4CFE6C83.70100@freebsd.org> References: <AANLkTin3njw-_4HRDw2en68LYhPC_XBDtXZp9U8gr3az@mail.gmail.com> <44B787D8-243C-4880-A532-261435C89940@gmail.com> <E00F6925-CEFD-465F-925F-5614210166CC@cederstrand.dk> <AANLkTimUQpQKBKb0FTqo_VjSCSDYAg9BkQEQ5197KsD4@mail.gmail.com> <4CFE6C83.70100@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 7, 2010 at 9:18 AM, Julian Elischer <julian@freebsd.org> wrote: > On 12/7/10 3:41 AM, Attilio Rao wrote: >> >> 2010/12/7 Erik Cederstrand<erik@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@gmail.com> =A0wrote: >>>> >>>>> A Dmesg.TXT is attached having a lock order reversal . >>>> >>>> =A0 =A0The 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 certai= nly 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 loc= k 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. I have a small patch against stable/7 that adds a single bit to each witness structure so that, if the "normal" lock order is ever encountered after a reversal, the stack is printed. It doesn't help when the order is defined statically, though. I could try to roll this up against -CURRENT this weekend. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikW4S1mf4%2BcyHV2PqSaYP14pxUYZzjaeho4a62v>