[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120225133213.GG184@brightrain.aerifal.cx>
Date: Sat, 25 Feb 2012 08:32:13 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: tough choice on thread pointer initialization issue
On Sat, Feb 25, 2012 at 01:56:13AM -0500, Rich Felker wrote:
> I've looked into the "solution 4" that Solar proposed, which simply
> put is making __pthread_self() check for a clobbered thread register
> and restore it. While this sounds simple, there are a few issues I've
> run into whereby it starts to get ugly...
Some revisions... it's not quite as bad as I said, but still not good
either..
> with, but from reading the kernel sources, it looks like %fs is 0 and
> a hidden 64-bit offset is stored in a privileged register accessible
> only by the kernel (one which hopefully would not be clobbered by
> sigreturn, but I'm not sure...) when the thread pointer does not fit
> in 32 bits, and the old i386 method (LDT entry and non-zero %fs
> selector value) is used when the thread pointer fits in 32 bits. This
Got the cases reversed I think, but the issue still stands.
> pointer is valid, we can't restore it (and the value of %fs might
> actually need to differ per-thread if some threads are below the 4gb
> boundary and others are located above).
Per-thread difference is irrelevant since only the main thread can
ever experience this problem; all new threads start with a valid
thread pointer.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
