From: Blaisorblade <blaisorblade@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: jdike@addtoit.com, Andi Kleen <ak@suse.de>
Subject: Re: [uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15]
Date: Sun, 9 Jul 2006 18:30:20 +0200 [thread overview]
Message-ID: <200607091830.21167.blaisorblade@yahoo.it> (raw)
In-Reply-To: <200606060139.18327.ak@suse.de>
On Tuesday 06 June 2006 01:39, Andi Kleen wrote:
> On Monday 05 June 2006 13:06, Blaisorblade wrote:
> > On Sunday 04 June 2006 21:06, Andi Kleen wrote:
> > > > It isn't yet perfect, because we don't yet save floating point
> > > > context. But that will come later. Additionally, there's a potential
> > > > problem since RED zones will alternate stacks are used, unlike
> > > > x86_64, so more stack space (128 bytes more) is used. But this
> > > > shouldn't be a problem. Instead, having no red zone (like x86_64)
> > >
> > > x86-64 has a red zone.
> >
> > On the alternate stack too?
> No, there not.
It has a redzone if a new signal handler is invoked.
> > The comment in the below code confused me... even
> > if when nesting signal frames sas_ss_flags(rsp) should be 0 and so the
> > redzone will be used.
> > The below "RED-PEN" comment is probably wrong then... or not?
> >
> > arch/x86_64/kernel/signal.c:
> > /* RED-PEN: redzone on that stack? */
>
> It's bogus because the alternative stack cannot be nested. I will remove
> it.
No, it's bogus because if we're already on the alternate stack sas_ss_flags()
won't return 0, but stacks can be nested (in that case the default path will
correctly setup a red zone).
From man sigaltstack:
Functions called from a signal handler executing on an alternate signal stack
will also use the alternate signal stack. (This also applies to any
handlers invoked for other signals while the process is executing on the
alternate signal stack.)
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
prev parent reply other threads:[~2006-07-09 16:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-04 18:52 [uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15] Paolo 'Blaisorblade' Giarrusso
2006-06-04 19:06 ` Andi Kleen
2006-06-05 11:06 ` Blaisorblade
2006-06-05 23:39 ` Andi Kleen
2006-07-09 16:30 ` Blaisorblade [this message]
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=200607091830.21167.blaisorblade@yahoo.it \
--to=blaisorblade@yahoo.it \
--cc=ak@suse.de \
--cc=jdike@addtoit.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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