Re: Assignment of GDT entries

[Jeremy Fitzhardinge <jeremy@goop.org>]

Mikael Pettersson wrote:
> The i386 TLS API has three components:
>
> (1) set_thread_area(entry_number == -1):
>     allocates and sets up the first available TLS entry and
>     copies the chosen GDT index back to user-space
> (2) set_thread_area(6 <= entry_number && entry_number <= 8):
>     allocates and sets up the indicated GDT entry
> (3) get_thread_area(6 <= entry_number && entry_number <= 8):
>     retrieves the contents of the indicated GDT entry
>
> Only (1) works in x86-64's ia32 emulation, the other two fail
> with EINVAL because x86-64 only accepts GDT indices 12 to 14
> for TLS entries. glibc only uses (1).
>
> If you move the i386 TLS GDT entries to other indices then you
> break (2) and (3) also on i386.
>   

(2) and (3) are always OK if you pass it the result of (1) - ie to 
update or readback a previously allocated descriptor.  Neither is useful 
without having done (1) first.  The fact that 32-on-32 and 32-on-64 
differ here means that nothing can (an apparently nothing does) depend 
on hardcoded knowledge of the TLS descriptor indicies anyway.

> It's not difficult to design a better i386 TLS API that avoids
> requiring user-space to know the actual GDT indices (just use
> logical TLS indices and always copy the GDT index to user-space).
> but unfortunately that doesn't help us
>   

You still need the real indicies to construct a selector to put into a 
segment register - ie, actually do something useful.  Changing the API 
to use abstract "TLS indicies" would also require a call to return the 
"TLS base", which hardly seems like an improvement.

Also, there's no inherent reason why the TLS indicies should be 
contigious; it happens to be true, but there's nothing useful userspace 
can do with that knowledge.  Allowing them to be discontigious may be 
helpful, for example, in packing the most used TLS entries (ie #1) into 
a hot cache line, while putting the lesser-used ones elsewhere.  The 
current API could deal with this without needing to change.

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