On 10/19/2015 07:39 PM, Leonid Yegoshin wrote: > MIPS32 o32 ABI sigaction() processing on MIPS64 n64 kernel was incorrectly > set to processing aka rt_sigaction() variant only. > > Fixed. > -- > V3: Signature added. > v2: Taken in account CONFIG vars interdependencies and conditional expression > simplified. As a result, the reverse problem fixed (introduced by v1). > Tested on all 3 ABIs. > -- > > Signed-off-by: Leonid Yegoshin <[email protected]> > --- > arch/mips/include/asm/signal.h | 12 +++++++++--- > arch/mips/kernel/signal.c | 2 +- > 2 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/arch/mips/include/asm/signal.h b/arch/mips/include/asm/signal.h > index 003e273eff4c..2292373ff11a 100644 > --- a/arch/mips/include/asm/signal.h > +++ b/arch/mips/include/asm/signal.h > @@ -11,11 +11,17 @@ > > #include <uapi/asm/signal.h> > > +#ifdef CONFIG_MIPS32_COMPAT > +extern struct mips_abi mips_abi_32; > > -#ifdef CONFIG_TRAD_SIGNALS > -#define sig_uses_siginfo(ka) ((ka)->sa.sa_flags & SA_SIGINFO) > +#define sig_uses_siginfo(ka, abi) \ > + ((abi != &mips_abi_32) ? 1 : \ > + ((ka)->sa.sa_flags & SA_SIGINFO)) > #else > -#define sig_uses_siginfo(ka) (1) > +#define sig_uses_siginfo(ka, abi) \ > + (config_enabled(CONFIG_64BIT) ? 1 : \ > + (config_enabled(CONFIG_TRAD_SIGNALS) ? \ > + ((ka)->sa.sa_flags & SA_SIGINFO) : 1) ) > #endif > > #include <asm/sigcontext.h> > diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c > index bf792e2839a6..5f18d0b879e0 100644 > --- a/arch/mips/kernel/signal.c > +++ b/arch/mips/kernel/signal.c > @@ -798,7 +798,7 @@ static void handle_signal(struct ksignal *ksig, struct > pt_regs *regs) > regs->regs[0] = 0; /* Don't deal with this again. > */ > } > > - if (sig_uses_siginfo(&ksig->ka)) > + if (sig_uses_siginfo(&ksig->ka, abi)) > ret = abi->setup_rt_frame(vdso + abi->vdso->off_rt_sigreturn, > ksig, regs, oldset); > else > >
What tree did you use for this patch? It does not seem to apply to mainline or Ralf's upstream-sfr. -- markos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
