Re: [PATCH 2/9] liblockdep: Wrap kernel/lockdep.c to allow usagefrom userspace

From: Sasha Levin
Date: Wed May 08 2013 - 09:53:56 EST


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/