[Top] [All Lists]

Re: [PATCH v3] kernel/signal.c: fix BUG_ON with SIG128 (MIPS)

To: Oleg Nesterov <>, David Daney <>
Subject: Re: [PATCH v3] kernel/signal.c: fix BUG_ON with SIG128 (MIPS)
From: James Hogan <>
Date: Mon, 24 Jun 2013 10:10:08 +0100
Cc: David Daney <>, <>, Ralf Baechle <>, Al Viro <>, Andrew Morton <>, Kees Cook <>, David Daney <>, "Paul E. McKenney" <>, David Howells <>, Dave Jones <>, <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
On 22/06/13 20:09, Oleg Nesterov wrote:
> On 06/21, David Daney wrote:
>> I am proposing that we just reduce the number of usable signals such
>> that existing libc status checking macros/functions don't change in any
>> way.
> And I fully agree! Absolutely, sorry for confusion.
> What I tried to say, _if_ we change the ABI instead, lets make this
> change sane.

I agree that this approach isn't very nice (I was really just trying to
explore the options) and reducing the number of signals is nicer. But is
anybody here confident enough that the number of signals changing under
the feet of existing binaries/libc won't actually break anything real?
I.e. anything trying to use SIGRTMAX() to get a lower priority signal.

> To me this hack is not sane. And btw, the patch doesn't look complete.
> Say, wait_task_zombie() should do exitcode_to_sig() for ->si_status.

Ah yes, I didn't seen that.


<Prev in Thread] Current Thread [Next in Thread>