mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mikael Pettersson <mikpe@it.uu.se>
To: acahalan@gmail.com, jeremy@goop.org
Cc: ak@suse.de, arjan@infradead.org, ebiederm@xmission.com,
	linux-kernel@vger.kernel.org, mingo@elte.hu, torvalds@osdl.org,
	zach@vmware.com
Subject: Re: Assignment of GDT entries
Date: Fri, 15 Sep 2006 09:55:20 +0200 (MEST)	[thread overview]
Message-ID: <200609150755.k8F7tKUD005518@alkaid.it.uu.se> (raw)

On Wed, 13 Sep 2006 23:11:05 -0700, Jeremy Fitzhardinge wrote:
>Albert Cahalan wrote:
>> We actually have an ABI problem right now because of this.
>> Note that i386 and x86_64 use different GDT slots.
>>
>> As far as I can tell, users need to hard-code the mapping
>> from TLS slot to segment number. They use 0,1,2 to ask the
>> kernel to set things up (via set_thread_area), but can't
>> just pop that into %fs or %gs.
>
>That's not true at all.  The program I posted earlier in this thread 
>uses set_thread_area() to allocate a GDT slot, and it works on both 
>native 32 bit and 32-under-64.

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.

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 now because the TLS GDT
indices must remain fixed as long as the current API is supported.

I _personally_ could certainly handle a post-2.6.18 kernel where
the improved API (new syscalls) is in place, the GDT indices have
been moved, and consequently components (2) and (3) of the old API
are broken. However, this still implies breaking binary compatibility,
which is not something to be done lightly.

(What's _really_ sad is that the implementation of the i386 TLS API
internally operates on logical TLS indices, it's just the syscall
interface that insists on requiring actual GDT indices from user-space.)

/Mikael

             reply	other threads:[~2006-09-15  7:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-15  7:55 Mikael Pettersson [this message]
2006-09-15  8:20 ` Jeremy Fitzhardinge
2006-09-15  8:58   ` Mikael Pettersson
2006-09-15 18:27     ` Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2006-09-14  4:06 Albert Cahalan
2006-09-14  4:44 ` Eric W. Biederman
2006-09-14  6:19   ` Albert Cahalan
2006-09-14  6:28     ` Zachary Amsden
2006-09-14  7:12       ` Albert Cahalan
2006-09-14  7:24         ` Zachary Amsden
2006-09-14  6:29     ` Jeremy Fitzhardinge
2006-09-14  3:23 Albert Cahalan
2006-09-14  6:11 ` Jeremy Fitzhardinge
2006-09-13 18:58 Jeremy Fitzhardinge
2006-09-13 19:16 ` Arjan van de Ven
2006-09-13 20:00   ` Alan Cox
2006-09-13 20:02     ` Jeremy Fitzhardinge
2006-09-13 20:20   ` Jeremy Fitzhardinge
2006-09-13 20:59     ` Zachary Amsden
2006-09-13 21:15       ` Jeremy Fitzhardinge
2006-09-13 21:35       ` Alan Cox
2006-09-14  0:25         ` Zachary Amsden
2006-09-14  1:40           ` Stephen Rothwell
2006-09-14 13:03           ` Alan Cox
2006-09-13 19:55 ` linux-os (Dick Johnson)
2006-09-13 20:08   ` Jeremy Fitzhardinge
2006-09-13 20:32     ` linux-os (Dick Johnson)
2006-09-13 21:21 ` Linus Torvalds
2006-09-13 21:47   ` Jeremy Fitzhardinge
2006-09-13 22:05     ` Linus Torvalds
2006-09-13 22:22       ` Jeremy Fitzhardinge
2006-09-14  6:00 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200609150755.k8F7tKUD005518@alkaid.it.uu.se \
    --to=mikpe@it.uu.se \
    --cc=acahalan@gmail.com \
    --cc=ak@suse.de \
    --cc=arjan@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.org \
    --cc=zach@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®