[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAG0J9_yJd5mf0t7whnKDYtf0AdZDnErjOgUga7t0p3TEL_9YQ@mail.gmail.com>
Date: Wed, 29 May 2013 22:56:44 +0100
From: James Hogan <james.hogan@...tec.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: David Daney <ddaney.cavm@...il.com>,
LKML <linux-kernel@...r.kernel.org>, linux-mips@...ux-mips.org,
Ralf Baechle <ralf@...ux-mips.org>,
Al Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
James Hogan <james.hogan@...tec.com>
Subject: Re: [RFC PATCH] kernel/signal.c: avoid BUG_ON with SIG128 (MIPS)
On 29 May 2013 18:36, Oleg Nesterov <oleg@...hat.com> wrote:
> On 05/29, David Daney wrote:
>>
>> On 05/29/2013 10:01 AM, James Hogan wrote:
>>> MIPS has 128 signals, the highest of which has the number 128. The
>>
>> I wonder if we should change the ABI and reduce the number of signals to
>> 127 instead of this patch.
>
> Same thoughts...
I'll give it a try. I wouldn't have thought it'd break anything, but
you never know. glibc (incorrectly) sets [__]SIGRTMAX to 127 already.
On the other hand uClibc sets it to 128, so anything built against
uClibc that uses signals SIGRTMAX-n (where n may be 0) or uses an
excessive number of rt signals starting from SIGRTMIN (sounds
unlikely) could well need an updated uClibc (or a full rebuild if it's
crazy enough to use __SIGRTMAX).
>>> @@ -2366,8 +2366,12 @@ relock:
>>>
>>> /*
>>> * Death signals, no core dump.
>>> + *
>>> + * MIPS has a signal number 128 which clashes with the core dump
>>> + * bit. If this was the signal we still want to report a valid
>>> + * exit code, so round it down to 127.
>>> */
>>> - do_group_exit(info->si_signo);
>>> + do_group_exit(min(info->si_signo, 127));
>
> This avoids BUG_ON() but obviously fools WIFSIGNALED(), doesn't look
> very nice.
Agreed.
Cheers
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists