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

[Sasha Levin]

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/