Re: [PATCH 2/2] MIPS: kernel: signal: Drop unused arguments for traditional signal handlers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/24/2015 01:01 AM, Markos Chandras wrote:
On 08/21/2015 06:03 PM, David Daney wrote:
On 08/20/2015 04:45 AM, Markos Chandras wrote:
Traditional signal handlers (ie !SA_SIGINFO) only need only argument
holding the signal number so we drop the additional arguments and fix
the related comments. We also update the comments for the SA_SIGINFO
case where the second argument is a pointer to a siginfo_t structure.

Signed-off-by: Markos Chandras <markos.chandras@xxxxxxxxxx>
---
   arch/mips/kernel/signal.c     | 6 +-----
   arch/mips/kernel/signal32.c   | 6 +-----
   arch/mips/kernel/signal_n32.c | 2 +-
   3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c
index be3ac5f7cbbb..3a125331bf8b 100644
--- a/arch/mips/kernel/signal.c
+++ b/arch/mips/kernel/signal.c
@@ -683,15 +683,11 @@ static int setup_frame(void *sig_return, struct
ksignal *ksig,
        * Arguments to signal handler:
        *
        *   a0 = signal number
-     *   a1 = 0 (should be cause)
-     *   a2 = pointer to struct sigcontext
        *
        * $25 and c0_epc point to the signal handler, $29 points to the
        * struct sigframe.
        */
       regs->regs[ 4] = ksig->sig;
-    regs->regs[ 5] = 0;
-    regs->regs[ 6] = (unsigned long) &frame->sf_sc;

This changes the kernel ABI.

Have you tested this change against all userspace applications that use
signals to make sure it doesn't break anything?

David Daney

i am confident there is no userland application that uses inline asm to
fetch additional arguments from (*sa_handler) when using !SA_SIGINFO

You don't need inline asm. All you have to do is use a C cast on the function pointer.

I think your confidence is misplaced. I have a program that this change will break.

You are changing the de facto kernel ABI in such a manner that it could break existing programs without a strong reason to do so.

Answer this: Why is it important to you to change this? The change log gives no justification other than we can, and it doesn't seem to break limited set of test cases.

If you are fixing some real bug, then OK. But if you don't have a reason to do this, then: NAK.

David Daney








[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux