From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752594AbeDMRIe (ORCPT ); Fri, 13 Apr 2018 13:08:34 -0400 Received: from foss.arm.com ([217.140.101.70]:44418 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752264AbeDMRIc (ORCPT ); Fri, 13 Apr 2018 13:08:32 -0400 Date: Fri, 13 Apr 2018 18:08:28 +0100 From: Dave Martin To: Linus Torvalds Cc: Russell King - ARM Linux , Linux Kernel Mailing List , "Dmitry V. Levin" , "Eric W. Biederman" , sparclinux , ppc-dev , linux-arm-kernel Subject: Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid Message-ID: <20180413170827.GB16308@e103592.cambridge.arm.com> References: <20180412095811.GC16141@n2100.armlinux.org.uk> <20180412110314.GA28070@altlinux.org> <20180412121949.GD16141@n2100.armlinux.org.uk> <20180412124928.GA29458@altlinux.org> <20180412131404.GE16141@n2100.armlinux.org.uk> <20180412172051.GK16141@n2100.armlinux.org.uk> <20180413094211.GN16141@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux > wrote: > > > > Yes, it does solve the problem at hand with strace - the exact patch I > > tested against 4.16 is below. > > Ok, good. > > > However, FPE_FLTUNK is not defined in older kernels, so while we can > > fix it this way for the current merge window, that doesn't help 4.16. > > I wonder if we should even bother with FPE_FLTUNK. > > I suspect we might as well use FPE_FLTINV, I suspect, and not have > this complexity at all. That case is not worth worrying about, since > it's a "this shouldn't happen anyway" and the *real* reason will be in > the kernel logs due to vfs_panic(). > > So it's not like this is something that the user should ever care > about the si_code about. Ack, my intended meaning for FPE_FLTUNK is that the fp exception is either spurious or we can't tell easily (or possibly at all) which FPE_XXX should be returned. It's up to userspace to figure it out if it really cares. Previously we were accidentally returning SI_USER in si_code for arm64. This case on arm looks like a more serious error for which FPE_FLTINV may be more appropriate anyway. [...] Cheers ---Dave