lkml.org 
[lkml]   [2006]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Assignment of GDT entries
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/

\
 
 \ /
  Last update: 2006-09-15 10:23    [W:0.029 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site