Guardian Digital Inc. >
Mailing List Archives >
Linux Kernel Mailing List Archive
On Wed, Dec 15, 2004 at 02:50:07AM -0800, Jeremy Fitzhardinge wrote:
> On Wed, 2004-12-15 at 05:27 +0100, Andi Kleen wrote:
> > From 64bit-from-32bit the lcall is needed agreed. However as a
> > warning it will not work for all calls since a few check a bit
> > in task_struct that says if the process is 32bit or 64bit
> > (rather rare though, most prominent is signal handling)
> When delivering a signal to a 64-bit process (ie, without TIF_IA32 set),
> do you think it should always set cs to be USER_CS? At the moment, if
> cs is something else (ie, USER32_CS), it tries to deliver the signal
> with that current...
Hmm, in theory you could handle a 64bit signal frame from 32bit code
(just may need an assembly stub if you want the arguments). But it
would be quite ugly agreed.
Perhaps it should force __USER_CS yes in this case, agreed.
There is a small risk of breaking someone, but it's very small.
I can do that change if you want.
BTW the long term plan is to get rid of the special cases to make
it easierto use the 32bit kernel ABI from a 64bit program.
This means signal handling will likely just check the code segment
at some point to decide if it should set up 32bit or 64bit frames
and we'll probably do similar things with the other cases
(except exec which needs to stay this way)
If you're interested in this I guess that could be done sooner
with some patch submissions (hint hint ;)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/