From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751553AbeDMTxw (ORCPT ); Fri, 13 Apr 2018 15:53:52 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:39362 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751111AbeDMTxu (ORCPT ); Fri, 13 Apr 2018 15:53:50 -0400 X-Google-Smtp-Source: AIpwx48pk72Qahx2pah0GT693N9dCKbjTeZO5/xMlMYt5vWih7ozATxycVZHUBp4I06bFsjY/fl20TWzHP5SPMnoung= MIME-Version: 1.0 In-Reply-To: <20180413184522.GD16308@e103592.cambridge.arm.com> References: <20180412124928.GA29458@altlinux.org> <20180412131404.GE16141@n2100.armlinux.org.uk> <20180412172051.GK16141@n2100.armlinux.org.uk> <20180413094211.GN16141@n2100.armlinux.org.uk> <20180413170827.GB16308@e103592.cambridge.arm.com> <20180413175407.GO16141@n2100.armlinux.org.uk> <20180413184522.GD16308@e103592.cambridge.arm.com> From: Linus Torvalds Date: Fri, 13 Apr 2018 12:53:49 -0700 X-Google-Sender-Auth: WgXg0_YEgoIjyxAGJtQfumuBS9w Message-ID: Subject: Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid To: Dave Martin Cc: Russell King - ARM Linux , Linux Kernel Mailing List , "Dmitry V. Levin" , "Eric W. Biederman" , sparclinux , ppc-dev , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote: > > Most uses I've seen do nothing more than use the FPE_xyz value to > format diagnostic messages while dying. I struggled to find code that > made a meaningful functional decision based on the value, though that's > not proof... Yeah. I've seen code that cares about SIGFPE deeply, but it's almost invariably about some emulated environment (eg Java VM, or CPU emulation). And the siginfo data is basically never good enough for those environments anyway on its own, so they will go and look at the actual instruction that caused the fault and the register state instead, because they need *all* the information. The cases that use si_code are the ones that just trapped signals in order to give a more helpful abort message. So I could certainly imagine that si_code is actually used by somebody who then decides to actuall act differently on it, but aside from perhaps printing out a different message, it sounds far-fetched. Linus