On Mon, Sep 30, 2013 at 6:29 AM, Baruch Siach <baruch@xxxxxxxxxx> 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 <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?
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html