lkml.org 
[lkml]   [2013]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2013-07-08 03:41    [W:0.098 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site