linux-kernel - Re: [RFC PATCH] kernel/signal.c: avoid BUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201306282203.56255.vda.linux@googlemail.com>
Date:	Fri, 28 Jun 2013 22:03:56 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	James Hogan <james.hogan@...tec.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	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>
Subject: Re: [RFC PATCH] kernel/signal.c: avoid BUG_ON with SIG128 (MIPS)

On Wednesday 29 May 2013 23:56, James Hogan wrote:
> 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).

Fixed in uclibc git: _NSIG is 128, __SIGRTMAX is 127
(_NSIG in libc is not the same as in kernel, but +1).

While at it, added extensive comment why it is so.
--
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/