Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935260Ab3E2V4x (ORCPT ); Wed, 29 May 2013 17:56:53 -0400 Received: from mail-qc0-f182.google.com ([209.85.216.182]:47309 "EHLO mail-qc0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935228Ab3E2V4p (ORCPT ); Wed, 29 May 2013 17:56:45 -0400 MIME-Version: 1.0 X-Originating-IP: [212.159.75.221] In-Reply-To: <20130529173634.GA2020@redhat.com> References: <1369846916-13202-1-git-send-email-james.hogan@imgtec.com> <51A638A4.2000705@gmail.com> <20130529173634.GA2020@redhat.com> Date: Wed, 29 May 2013 22:56:44 +0100 X-Google-Sender-Auth: 0UnJQ0Vw4BWJ322ZjkdkCqs6n3s Message-ID: Subject: Re: [RFC PATCH] kernel/signal.c: avoid BUG_ON with SIG128 (MIPS) From: James Hogan To: Oleg Nesterov Cc: David Daney , LKML , linux-mips@linux-mips.org, Ralf Baechle , Al Viro , Andrew Morton , Kees Cook , James Hogan Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1609 Lines: 43 On 29 May 2013 18:36, Oleg Nesterov 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/