Messages in this thread | | | Date | Sun, 07 Jul 2013 21:14:38 -0400 | From | Sasha Levin <> | Subject | Re: [Patch v5 0/9] liblockdep: userspace lockdep |
| |
On 06/27/2013 09:55 AM, Sasha Levin wrote: > On 06/27/2013 05:07 AM, Ingo Molnar wrote: >> >> * Sasha Levin <sasha.levin@oracle.com> wrote: >> >>> On 06/26/2013 11:53 AM, Ingo Molnar wrote: >>>>> Ingo, I don't think I see anything holding this back; however I remember >>>>>> reading some email about people not liking stuff like this living in the >>>>>> tools/ directory or such. >>>>>> >>>>>> Will you pick this up? >>>> So I'd really be interested in how interesting/useful this is to userspace >>>> developers? Does it work for something complex as Firefox, or Apache, to >>>> the extent they make use of these locking APIs? >>> >>> So far I've tested it on Firefox, Apache, QEMU, LKVM, GCC and random >>> smallish programs. I haven't really done full testing for each of those, >>> but just made sure that liblockdep behaves as it supposed to. I'm >>> guessing that with further work it will dig up actual issues. >> >> The other issue is that with lock classes disabled you have to hit an >> actual deadlock to trigger any output. >> >> I.e. much of the power of lockdep is diminished :-/ When actual deadlocks >> are triggered then it's not particularly complex to debug user-space apps: >> gdb the hung task(s) and look at the backtraces. > > Lock classes are disabled only if you're using the LD_PRELOAD method of > testing. If you actually re-compile your code with the library (by just > including the header and setting a #define to enable it) you will have > lock classes.
Hi Ingo,
Just wondering if you're planning on pushing it over to Linus from your tree, or should I go ahead and do it on my own?
Thanks, Sasha
| |