lkml.org 
[lkml]   [2013]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/9] liblockdep: Wrap kernel/lockdep.c to allow usage from userspace
On 05/08/2013 09:35 AM, Peter Zijlstra wrote:
> On Wed, May 08, 2013 at 09:27:46AM -0400, Sasha Levin wrote:
>> [snip]
>>
>> Hi Peter,
>>
>> You're right - I broke multithreading for some odd reason (mostly me being stupid)
>> after having it working :/
>>
>> It's enough to set the __thread flag on current_obj:
>>
>> diff --git a/tools/lib/lockdep/common.c b/tools/lib/lockdep/common.c
>> index eb5e481..8ef602f 100644
>> --- a/tools/lib/lockdep/common.c
>> +++ b/tools/lib/lockdep/common.c
>> @@ -5,7 +5,7 @@
>> #include <unistd.h>
>> #include <sys/syscall.h>
>>
>> -static struct task_struct current_obj;
>> +static __thread struct task_struct current_obj;
>>
>> /* lockdep wants these */
>> bool debug_locks = true;
>>
>> Since we don't need any special initialization of the struct at any point. This
>> means that the patch above is enough and we don't need to hook pthread_create.
>>
>
> I tried googling but failed to find the TLS initialization rules. Are they
> zero'd for each thread or copied about or what? And is this documented or
> implementation behaviour?
>
> If its consistently zero'd then I suppose you're right and we can get away with
> just adding __thread; *phew*.

I assumed that they are zero'd because it is a global variable, and those are
supposed to be zero'd.

Running a quick test confirmed that they are indeed zero'd for each thread, so
we're safe to just add that __thread.


Thanks,
Sasha



\
 
 \ /
  Last update: 2013-05-08 16:21    [W:0.037 / U:1.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site