On Mon, Sep 30, 2013 at 6:29 AM, Baruch Siach <[email protected]> wrote: > 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 <[email protected]> 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: <[email protected]> >> > Signed-off-by: Baruch Siach <[email protected]> >> > --- >> > 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?
The redundancy mentioned in that commit is due to the outer "if (!onsigstack)"; in our case "!on_sig_stack(sp)" is explicitly checked in the same expression, and I'm proposing to get rid of it. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
