All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney.cavm@gmail.com>
To: James Hogan <james.hogan@imgtec.com>
Cc: linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	David Daney <david.daney@cavium.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	David Howells <dhowells@redhat.com>,
	Dave Jones <davej@redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH v3] kernel/signal.c: fix BUG_ON with SIG128 (MIPS)
Date: Fri, 21 Jun 2013 08:59:32 -0700	[thread overview]
Message-ID: <51C47864.9030200@gmail.com> (raw)
In-Reply-To: <1371821962-9151-1-git-send-email-james.hogan@imgtec.com>

On 06/21/2013 06:39 AM, James Hogan wrote:
> MIPS has 128 signals, the highest of which has the number 128 (they
> start from 1). The following command causes get_signal_to_deliver() to
> pass this signal number straight through to do_group_exit() as the exit
> code:
>
>    strace sleep 10 & sleep 1 && kill -128 `pidof sleep`
>
> However do_group_exit() checks for the core dump bit (0x80) in the exit
> code which matches in this particular case and the kernel panics:
>
>    BUG_ON(exit_code & 0x80); /* core dumps don't get here */
>
> Fundamentally the exit / wait status code cannot represent SIG128. In
> fact it cannot represent SIG127 either as 0x7f represents a stopped
> child.
>
> Therefore add sig_to_exitcode() and exitcode_to_sig() functions which
> map signal numbers > 126 to exit code 126 and puts the remainder (i.e.
> sig - 126) in higher bits. This allows WIFSIGNALED() to return true for
> both SIG127 and SIG128, and allows WTERMSIG to be later updated to read
> the correct signal number for SIG127 and SIG128.

I really hate this approach.

Can we just change the ABI to reduce the number of signals so that all 
the standard C library wait related macros don't have to be changed?

Think about it, any user space program using signal numbers 127 and 128 
doesn't work correctly as things exist today, so removing those two will 
be no great loss.

David Daney


>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: David Daney <david.daney@cavium.com>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Dave Jones <davej@redhat.com>
> Cc: linux-mips@linux-mips.org
> ---
> v3:
>
> A slightly different approach this time, closer to the original patch I
> sent. This is because reducing _NSIG to 127 (like v2) still leaves
> incorrect exit status codes for SIG127. The only ABI this changes is the
> wait/waitpid status code, and it's in such a way that old binaries, as
> long as they use the macros defined in the wait manpage, should see a
> process terminated by signal 126 for SIG127 and SIG128 rather than
> !WIFSIGNALED(). Software rebuilt with updated libc wait status macros
> would see the correct terminating signal number.
>
>   kernel/signal.c | 32 +++++++++++++++++++++++++++++---
>   1 file changed, 29 insertions(+), 3 deletions(-)
>


  reply	other threads:[~2013-06-21 15:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21 13:39 [PATCH v3] kernel/signal.c: fix BUG_ON with SIG128 (MIPS) James Hogan
2013-06-21 13:39 ` James Hogan
2013-06-21 15:59 ` David Daney [this message]
2013-06-21 16:12   ` Ralf Baechle
2013-06-21 20:22   ` Oleg Nesterov
2013-06-21 20:45     ` David Daney
2013-06-21 20:45       ` David Daney
2013-06-22 19:09       ` Oleg Nesterov
2013-06-24  9:10         ` James Hogan
2013-06-24  9:10           ` James Hogan
2013-06-25 21:40           ` Andrew Morton
2013-06-25 21:40             ` Andrew Morton
2013-06-25 22:13             ` James Hogan
2013-06-26 11:07               ` James Hogan
2013-06-26 11:07                 ` James Hogan
2013-06-26 11:07                 ` James Hogan
2013-06-26 16:01                 ` Ralf Baechle
2013-06-26 16:14                 ` Oleg Nesterov
2013-06-26 16:59                   ` Ralf Baechle
2013-06-26 17:15                     ` Oleg Nesterov
2013-06-28 12:07                       ` James Hogan
2013-06-28 12:07                         ` James Hogan
2013-06-28 17:55                         ` Oleg Nesterov
2013-06-28 20:09                     ` Denys Vlasenko
2013-06-24  9:26   ` James Hogan
2013-06-24  9:26     ` James Hogan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51C47864.9030200@gmail.com \
    --to=ddaney.cavm@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=david.daney@cavium.com \
    --cc=dhowells@redhat.com \
    --cc=james.hogan@imgtec.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=ralf@linux-mips.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.