From: Andi Kleen <ak@suse.de>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andi Kleen <ak@suse.de>, Petr Vandrovec <VANDROVE@vc.cvut.cz>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 32-bit syscalls from 64-bit process on x86-64?
Date: Wed, 15 Dec 2004 11:55:10 +0100 [thread overview]
Message-ID: <20041215105510.GF27225@wotan.suse.de> (raw)
In-Reply-To: <1103107807.24540.23.camel@localhost>
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 ;)
-Andi
next prev parent reply other threads:[~2004-12-15 10:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-14 22:01 32-bit syscalls from 64-bit process on x86-64? Petr Vandrovec
2004-12-15 4:27 ` Andi Kleen
2004-12-15 10:50 ` Jeremy Fitzhardinge
2004-12-15 10:55 ` Andi Kleen [this message]
2004-12-15 20:58 ` Jeremy Fitzhardinge
2004-12-16 4:35 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2004-12-02 16:22 Jeremy Fitzhardinge
2004-12-02 18:52 ` Jeremy Fitzhardinge
2004-12-03 6:15 ` Andi Kleen
2004-12-03 23:16 ` Jeremy Fitzhardinge
2004-12-04 14:40 ` Petr Vandrovec
2004-12-04 21:33 ` Jeremy Fitzhardinge
2004-12-08 2:30 ` Jeremy Fitzhardinge
2004-12-14 7:45 ` 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=20041215105510.GF27225@wotan.suse.de \
--to=ak@suse.de \
--cc=VANDROVE@vc.cvut.cz \
--cc=jeremy@goop.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.