From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE Date: Fri, 30 Jun 2017 13:13:40 -0500 Message-ID: <8737ahwdgr.fsf@xmission.com> References: <87efu22set.fsf@xmission.com> <20170630123906.8865-3-ebiederm@xmission.com> <20170630.124505.736865959393416284.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170630.124505.736865959393416284.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> (David Miller's message of "Fri, 30 Jun 2017 12:45:05 -0400 (EDT)") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: David Miller Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, avagin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org, greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, xemul-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org, oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, w@1wt.eu, avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org List-Id: containers.vger.kernel.org David Miller writes: > From: "Eric W. Biederman" > Date: Fri, 30 Jun 2017 07:39:01 -0500 > >> diff --git a/arch/sparc/include/uapi/asm/siginfo.h b/arch/sparc/include/uapi/asm/siginfo.h >> index 2d9b79ccaa50..6bc5c677e92f 100644 >> --- a/arch/sparc/include/uapi/asm/siginfo.h >> +++ b/arch/sparc/include/uapi/asm/siginfo.h >> @@ -17,6 +17,11 @@ >> #define SI_NOINFO 32767 /* no information in siginfo_t */ >> >> /* >> + * SIGFPE si_codes >> + */ >> +#define FPE_FIXME (__SI_FAULT|0) /* Broken dup of SI_USER */ >> + >> +/* >> * SIGEMT si_codes >> */ >> #define EMT_TAGOVF (__SI_FAULT|1) /* tag overflow */ > > It's one thing to say FIXME in a comment in a kernel local header or > C file. > > It's quite another to put this into the name of a macro which has > visibility in the global user compilation namespace. > > I don't think you should really do that. Good point. Sigh. It almost fits because we did do something off in the uapi exported to userspace and we don't have a header file definition for that case. Still. At this point arch/sparc/include/asm/siginfo.h is a better fit for that definition. I will respin and fix that. I wish I knew what would make a better default floating point si_code on sparc. Using 0 aka SI_USER is doesn't fit at all. Sigh. Unfortunately I don't know the architecture well enough to even guess what is going on in do_fpe_common when when no bits in fsr are set. Any suggests for a better fix than just documenting that linux does something weird and ill advised here? Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752448AbdF3SVE (ORCPT ); Fri, 30 Jun 2017 14:21:04 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:58916 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751918AbdF3SVC (ORCPT ); Fri, 30 Jun 2017 14:21:02 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: David Miller Cc: linux-kernel@vger.kernel.org, luto@kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, oleg@redhat.com, avagin@virtuozzo.com, tglx@linutronix.de, greg@kroah.com, avagin@openvz.org, serge@hallyn.com, xemul@virtuozzo.com, gorcunov@openvz.org, peterz@infradead.org, w@1wt.eu, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, mtk.manpages@gmail.com, sparclinux@vger.kernel.org References: <87efu22set.fsf@xmission.com> <20170630123906.8865-3-ebiederm@xmission.com> <20170630.124505.736865959393416284.davem@davemloft.net> Date: Fri, 30 Jun 2017 13:13:40 -0500 In-Reply-To: <20170630.124505.736865959393416284.davem@davemloft.net> (David Miller's message of "Fri, 30 Jun 2017 12:45:05 -0400 (EDT)") Message-ID: <8737ahwdgr.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dR0XD-0007pC-TM;;;mid=<8737ahwdgr.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+CTLTDmU6sT6USglK1J9zo90rLDviBxyo= X-SA-Exim-Connect-IP: 67.3.213.87 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 URIBL_SBL_A Contains URL's A record listed in the SBL blocklist * [URIs: davemloft.net] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;David Miller X-Spam-Relay-Country: X-Spam-Timing: total 5697 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.5 (0.0%), b_tie_ro: 1.61 (0.0%), parse: 1.29 (0.0%), extract_message_metadata: 29 (0.5%), get_uri_detail_list: 1.99 (0.0%), tests_pri_-1000: 13 (0.2%), tests_pri_-950: 2.4 (0.0%), tests_pri_-900: 2.0 (0.0%), tests_pri_-400: 30 (0.5%), check_bayes: 28 (0.5%), b_tokenize: 11 (0.2%), b_tok_get_all: 8 (0.1%), b_comp_prob: 3.8 (0.1%), b_tok_touch_all: 2.7 (0.0%), b_finish: 0.89 (0.0%), tests_pri_0: 2272 (39.9%), check_dkim_signature: 0.61 (0.0%), check_dkim_adsp: 2005 (35.2%), tests_pri_500: 3339 (58.6%), poll_dns_idle: 3331 (58.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Miller writes: > From: "Eric W. Biederman" > Date: Fri, 30 Jun 2017 07:39:01 -0500 > >> diff --git a/arch/sparc/include/uapi/asm/siginfo.h b/arch/sparc/include/uapi/asm/siginfo.h >> index 2d9b79ccaa50..6bc5c677e92f 100644 >> --- a/arch/sparc/include/uapi/asm/siginfo.h >> +++ b/arch/sparc/include/uapi/asm/siginfo.h >> @@ -17,6 +17,11 @@ >> #define SI_NOINFO 32767 /* no information in siginfo_t */ >> >> /* >> + * SIGFPE si_codes >> + */ >> +#define FPE_FIXME (__SI_FAULT|0) /* Broken dup of SI_USER */ >> + >> +/* >> * SIGEMT si_codes >> */ >> #define EMT_TAGOVF (__SI_FAULT|1) /* tag overflow */ > > It's one thing to say FIXME in a comment in a kernel local header or > C file. > > It's quite another to put this into the name of a macro which has > visibility in the global user compilation namespace. > > I don't think you should really do that. Good point. Sigh. It almost fits because we did do something off in the uapi exported to userspace and we don't have a header file definition for that case. Still. At this point arch/sparc/include/asm/siginfo.h is a better fit for that definition. I will respin and fix that. I wish I knew what would make a better default floating point si_code on sparc. Using 0 aka SI_USER is doesn't fit at all. Sigh. Unfortunately I don't know the architecture well enough to even guess what is going on in do_fpe_common when when no bits in fsr are set. Any suggests for a better fix than just documenting that linux does something weird and ill advised here? Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Date: Fri, 30 Jun 2017 18:13:40 +0000 Subject: Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE Message-Id: <8737ahwdgr.fsf@xmission.com> List-Id: References: <87efu22set.fsf@xmission.com> <20170630123906.8865-3-ebiederm@xmission.com> <20170630.124505.736865959393416284.davem@davemloft.net> In-Reply-To: <20170630.124505.736865959393416284.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> (David Miller's message of "Fri, 30 Jun 2017 12:45:05 -0400 (EDT)") MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Miller Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, avagin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org, greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, xemul-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org, oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, w@1wt.eu, avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org David Miller writes: > From: "Eric W. Biederman" > Date: Fri, 30 Jun 2017 07:39:01 -0500 > >> diff --git a/arch/sparc/include/uapi/asm/siginfo.h b/arch/sparc/include/uapi/asm/siginfo.h >> index 2d9b79ccaa50..6bc5c677e92f 100644 >> --- a/arch/sparc/include/uapi/asm/siginfo.h >> +++ b/arch/sparc/include/uapi/asm/siginfo.h >> @@ -17,6 +17,11 @@ >> #define SI_NOINFO 32767 /* no information in siginfo_t */ >> >> /* >> + * SIGFPE si_codes >> + */ >> +#define FPE_FIXME (__SI_FAULT|0) /* Broken dup of SI_USER */ >> + >> +/* >> * SIGEMT si_codes >> */ >> #define EMT_TAGOVF (__SI_FAULT|1) /* tag overflow */ > > It's one thing to say FIXME in a comment in a kernel local header or > C file. > > It's quite another to put this into the name of a macro which has > visibility in the global user compilation namespace. > > I don't think you should really do that. Good point. Sigh. It almost fits because we did do something off in the uapi exported to userspace and we don't have a header file definition for that case. Still. At this point arch/sparc/include/asm/siginfo.h is a better fit for that definition. I will respin and fix that. I wish I knew what would make a better default floating point si_code on sparc. Using 0 aka SI_USER is doesn't fit at all. Sigh. Unfortunately I don't know the architecture well enough to even guess what is going on in do_fpe_common when when no bits in fsr are set. Any suggests for a better fix than just documenting that linux does something weird and ill advised here? Eric