Hi Max,
On Mon, Sep 30, 2013 at 04:23:47AM +0400, Max Filippov wrote:
> On Sun, Sep 29, 2013 at 3:58 PM, Baruch Siach <baruch@xxxxxxxxxx> wrote:
> > According to create_thread(3): "The new thread does not inherit the creating
> > thread's alternate signal stack". Since commit f9a3879a (Fix sigaltstack
> > corruption among cloned threads), current->sas_ss_size is set to 0 for cloned
> > processes sharing VM with their parent. Don't use the (nonexistent) alternate
> > signal stack in this case.
> >
> > Fixes the SA_ONSTACK part of the nptl/tst-cancel20 test from uClibc.
> >
> > Also fix a checkpatch.pl error, while at it.
> >
> > Cc: <stable@xxxxxxxxxxxxxxx>
> > Signed-off-by: Baruch Siach <baruch@xxxxxxxxxx>
> > ---
> > arch/xtensa/kernel/signal.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/xtensa/kernel/signal.c b/arch/xtensa/kernel/signal.c
> > index 718eca1..ef94d82 100644
> > --- a/arch/xtensa/kernel/signal.c
> > +++ b/arch/xtensa/kernel/signal.c
> > @@ -341,7 +341,8 @@ static int setup_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
> >
> > sp = regs->areg[1];
> >
> > - if ((ka->sa.sa_flags & SA_ONSTACK) != 0 && ! on_sig_stack(sp)) {
> > + if ((ka->sa.sa_flags & SA_ONSTACK) != 0 && !on_sig_stack(sp)
> > + && current->sas_ss_size != 0) {
>
> Looks like
> if ((ka->sa.sa_flags & SA_ONSTACK) && (sas_ss_flags(sp) == 0))
> is used more often here among other arches. Mind changing it this way?
According to the commit log of 0f8f30892 (x86: signal: check sas_ss_size
instead of sas_ss_flags()) "Checking on_sig_stack() in sas_ss_flags() at
get_sigframe() is redundant and not correct on 64 bit". The 64 bit part
doesn't apply here, but I guess the redundant part does. Isn't it?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@xxxxxxxxxx - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html