From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750926AbcFDFI1 (ORCPT ); Sat, 4 Jun 2016 01:08:27 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:36236 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750718AbcFDFIZ (ORCPT ); Sat, 4 Jun 2016 01:08:25 -0400 MIME-Version: 1.0 In-Reply-To: <1464786697-20639-7-git-send-email-dsafonov@virtuozzo.com> References: <1464786697-20639-1-git-send-email-dsafonov@virtuozzo.com> <1464786697-20639-7-git-send-email-dsafonov@virtuozzo.com> From: Andy Lutomirski Date: Fri, 3 Jun 2016 22:08:04 -0700 Message-ID: Subject: Re: [PATCH 6/6] x86/signal: add SA_{X32,IA32}_ABI sa_flags To: Dmitry Safonov Cc: "H. Peter Anvin" , Dmitry Safonov <0x7f454c46@gmail.com>, khorenko@virtuozzo.com, "linux-kernel@vger.kernel.org" , Thomas Gleixner , Cyrill Gorcunov , Oleg Nesterov , xemul@virtuozzo.com, X86 ML , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Jun 1, 2016 6:13 AM, "Dmitry Safonov" wrote: > > Introduce new flags that defines which ABI to use on creating sigframe. > Those flags kernel will set according to sigaction syscall ABI, > which set handler for the signal being delivered. > > So that will drop the dependency on TIF_IA32/TIF_X32 flags on signal deliver. > Those flags will be used only under CONFIG_COMPAT. > > Similar way ARM uses sa_flags to differ in which mode deliver signal > for 26-bit applications (look at SA_THIRYTWO). > > Cc: Andy Lutomirski > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: "H. Peter Anvin" > Cc: Oleg Nesterov > Signed-off-by: Dmitry Safonov > --- > arch/x86/ia32/ia32_signal.c | 2 +- > arch/x86/include/asm/fpu/signal.h | 6 ++++++ > arch/x86/include/uapi/asm/signal.h | 6 +++++- > arch/x86/kernel/signal.c | 19 ++++++++++--------- > arch/x86/kernel/signal_compat.c | 30 +++++++++++++++++++++++++++--- > kernel/signal.c | 5 +++++ > 6 files changed, 54 insertions(+), 14 deletions(-) > > diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c > index 2f29f4e407c3..cb13c0564ea7 100644 > --- a/arch/x86/ia32/ia32_signal.c > +++ b/arch/x86/ia32/ia32_signal.c > @@ -378,7 +378,7 @@ int ia32_setup_rt_frame(int sig, struct ksignal *ksig, > put_user_ex(*((u64 *)&code), (u64 __user *)frame->retcode); > } put_user_catch(err); > > - err |= copy_siginfo_to_user32(&frame->info, &ksig->info); > + err |= __copy_siginfo_to_user32(&frame->info, &ksig->info, false); > err |= ia32_setup_sigcontext(&frame->uc.uc_mcontext, fpstate, > regs, set->sig[0]); > err |= __copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set)); > diff --git a/arch/x86/include/asm/fpu/signal.h b/arch/x86/include/asm/fpu/signal.h > index 0e970d00dfcd..20a1fbf7fe4e 100644 > --- a/arch/x86/include/asm/fpu/signal.h > +++ b/arch/x86/include/asm/fpu/signal.h > @@ -19,6 +19,12 @@ int ia32_setup_frame(int sig, struct ksignal *ksig, > # define ia32_setup_rt_frame __setup_rt_frame > #endif > > +#ifdef CONFIG_COMPAT > +int __copy_siginfo_to_user32(compat_siginfo_t __user *to, > + const siginfo_t *from, bool x32_ABI); > +#endif > + > + > extern void convert_from_fxsr(struct user_i387_ia32_struct *env, > struct task_struct *tsk); > extern void convert_to_fxsr(struct task_struct *tsk, > diff --git a/arch/x86/include/uapi/asm/signal.h b/arch/x86/include/uapi/asm/signal.h > index 8264f47cf53e..9c663b6fc023 100644 > --- a/arch/x86/include/uapi/asm/signal.h > +++ b/arch/x86/include/uapi/asm/signal.h > @@ -70,6 +70,8 @@ typedef unsigned long sigset_t; > * SA_RESETHAND clears the handler when the signal is delivered. > * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies. > * SA_NODEFER prevents the current signal from being masked in the handler. > + * SA_IA32_ABI/SA_X32_ABI indicates ABI for a signal frame, > + * if neither is set, the kernel will set them according to a syscall ABI I would prefer if these weren't in the UAPI header. If you want a foreign signal frame type, do a foreign syscall. This also means that you should strip these flags if a user sets them directly. --Andy