From: Ulrich Drepper <drepper@redhat.com>
To: Andi Kleen <ak@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Better CLONE_SETTLS support for Hammer
Date: Wed, 05 Mar 2003 19:53:40 -0800 [thread overview]
Message-ID: <3E66C644.2020300@redhat.com> (raw)
In-Reply-To: <20030306010517.GB17865@wotan.suse.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andi Kleen wrote:
> You want the change, not me ;)
But I cannot test it since the kernel doesn't work.
> It should already work on the current kernel, modulo clone.
> (but arch_prctl, set_thread_area in 2.5, ldt in 2.4 etc.)
I cannot confirm this. I wasted a lot of time on getting it to work.
Without avail.
> It's needed for 32bit emulation at least. The code is 100% shared
> between the emulation and the native 64bit model.
> In theory it could be removed from the system call table for 64bit
> but there didn't seem a good reason to do so - after all 64bit programs
> can put their thread local data into the first 4GB and
> fast context switches.
>
>
>>the use of prctl to get and set the base address. Then internally in
>>the prctl call map it to either the use of a 32 base address segment or
>>use the MSR.
>
>
> The problem is that the 64bit base has different semantics.
>
> When you use a segment register you have to do:
>
> call kernel to set gdt/ldt
> movl index,%%fs
>
> But when the kernel did set the 64bit base in the kernel call the
> following movl to the selector would destroy it again
>
> Loading the index inside the system call would also be problematic:
> First it would be different from what i386 does, causing porting headaches.
> Also you could not easily do it from a different thread unlike the
> LDT load.
>
>
>
>>This way whoever needs a segment base address can preferably allocate it
>>in the low 4GB, but if it fails the kernel support still work. And with
>>the same interface. Currently this is not the case and this is not
>>acceptable.
>
>
> That should already work and it is in fact how I imagined this to be:
>
> do MAP_32BIT - if yes use set_thread_area or an LDT entry;
>
> if not use arch_prctl
>
> The NPTL signal race problem for the clones in case you have a 64bit
> base is a bit ugly though I agree.
>
> I don't like your patch currently because it'll guarantee slow
> context switch times for 64bit.
>
> Automatic switching based on the set bits in the base may be possible
> (in fact I had something like this in set_thread_area for some time, but
> removed it because of the ugly semantics because set_thread_area doesn't
> already load the selector). If the selector load is forced
> in clone however it would not be as weird, just only somewhat
> ugly. You'll have to guarantee in user space then that you don't
> reload it.
>
> Real solution would be Windowish - Create clone7() with both
> selectors and bases
>
> [I suspect 2.8 and 3.0 will get that anyways as experience
> on other operating systems who started on the same path
> shows. e.g. AmigaOS grew more CreateTask
> variants with more arguments with each release until they eventually
> settled on passing tag lists.]
>
> -Andi
>
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+ZsZE2ijCOnn/RHQRAphoAJ9YRohA3FrNkAWrTlk0nigBj1/NCwCdGmkR
uxv9VRkBY//SftCcmk2KwgQ=
=W1al
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2003-03-06 3:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-05 18:55 Better CLONE_SETTLS support for Hammer Ulrich Drepper
2003-03-05 19:06 ` Andi Kleen
2003-03-05 19:25 ` Ulrich Drepper
2003-03-05 21:19 ` Andi Kleen
2003-03-05 19:32 ` Ulrich Drepper
2003-03-05 21:21 ` Andi Kleen
2003-03-05 23:04 ` Ulrich Drepper
2003-03-06 1:05 ` Andi Kleen
2003-03-06 3:53 ` Ulrich Drepper [this message]
2003-03-06 4:14 ` Ulrich Drepper
2003-03-06 10:27 ` Andi Kleen
2003-03-06 18:58 ` Ulrich Drepper
2003-03-06 19:09 ` Andi Kleen
2003-03-06 2:08 ` Benjamin LaHaise
2003-03-06 3:52 ` Ulrich Drepper
2003-03-06 5:29 ` Benjamin LaHaise
2003-03-06 5:47 ` Ulrich Drepper
2003-03-06 5:33 ` H. Peter Anvin
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=3E66C644.2020300@redhat.com \
--to=drepper@redhat.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).