From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752110Ab3FXJKO (ORCPT ); Mon, 24 Jun 2013 05:10:14 -0400 Received: from multi.imgtec.com ([194.200.65.239]:34586 "EHLO multi.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751177Ab3FXJKM (ORCPT ); Mon, 24 Jun 2013 05:10:12 -0400 Message-ID: <51C80CF0.4070608@imgtec.com> Date: Mon, 24 Jun 2013 10:10:08 +0100 From: James Hogan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Oleg Nesterov , David Daney CC: David Daney , , Ralf Baechle , Al Viro , Andrew Morton , Kees Cook , David Daney , "Paul E. McKenney" , David Howells , Dave Jones , Subject: Re: [PATCH v3] kernel/signal.c: fix BUG_ON with SIG128 (MIPS) References: <1371821962-9151-1-git-send-email-james.hogan@imgtec.com> <51C47864.9030200@gmail.com> <20130621202244.GA16610@redhat.com> <51C4BB86.1020004@caviumnetworks.com> <20130622190940.GA14150@redhat.com> In-Reply-To: <20130622190940.GA14150@redhat.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.154.65] X-SEF-Processed: 7_3_0_01192__2013_06_24_10_10_10 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Cheers James From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from multi.imgtec.com ([194.200.65.239]:34579 "EHLO multi.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S6815757Ab3FXJKQ0fy55 (ORCPT ); Mon, 24 Jun 2013 11:10:16 +0200 Message-ID: <51C80CF0.4070608@imgtec.com> Date: Mon, 24 Jun 2013 10:10:08 +0100 From: James Hogan MIME-Version: 1.0 Subject: Re: [PATCH v3] kernel/signal.c: fix BUG_ON with SIG128 (MIPS) References: <1371821962-9151-1-git-send-email-james.hogan@imgtec.com> <51C47864.9030200@gmail.com> <20130621202244.GA16610@redhat.com> <51C4BB86.1020004@caviumnetworks.com> <20130622190940.GA14150@redhat.com> In-Reply-To: <20130622190940.GA14150@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Oleg Nesterov , David Daney Cc: David Daney , linux-kernel@vger.kernel.org, Ralf Baechle , Al Viro , Andrew Morton , Kees Cook , David Daney , "Paul E. McKenney" , David Howells , Dave Jones , linux-mips@linux-mips.org Message-ID: <20130624091008.-IGFSkUD0MPSFLtRpIMvRAVHxWy81-p7eYbI3dYsfT4@z> 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. Cheers James