From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 440B1C3F68F for ; Thu, 12 Dec 2019 18:28:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1A3C822527 for ; Thu, 12 Dec 2019 18:28:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rwpGXTJO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A3C822527 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:MIME-Version:Message-ID: In-Reply-To:Date:References:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XhGk++AzyEUG0cJv5ZDQnX85EVNbAxIkOTMIoBgQAtI=; b=rwpGXTJOAFXDX+ bbkduCcxpAy1oni2lUMcYWRqAn5fh1b/mZ9NQGC7jpBszN2vmvONAtMpk0yD0BWy0BuAOeyDMqf0K siFJD7jNqdnLUTwtQp7T9/m2eMC5o/B/8imvVzl7tNg8eirWmRgdZaAFVH9vo3PQOEG/Bw4qD5c9/ Rp0DvlAdYhMaf1pK+A3PKY/T1MK/r3XRo6fjg64GE603Bx9j4HUHRCDkKIcFk/XVBjSzoY7Wdgld2 E15pFRRBQqyIuV0mEPVg89D+aQH31NqS+4aDpYlavgRo3n+QAnPXJEvsgguSnmN2RPgYjW9e1G8dw mqIDCS1BogKvqcsUdJhQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ifTCJ-0003DU-9o; Thu, 12 Dec 2019 18:28:23 +0000 Received: from out02.mta.xmission.com ([166.70.13.232]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ifTCG-0003CD-FV for linux-arm-kernel@lists.infradead.org; Thu, 12 Dec 2019 18:28:22 +0000 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ifTBW-0006da-Da; Thu, 12 Dec 2019 11:27:34 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1ifTBV-0007Vb-8k; Thu, 12 Dec 2019 11:27:34 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Arnd Bergmann References: <20191211184027.20130-1-catalin.marinas@arm.com> <20191211184027.20130-13-catalin.marinas@arm.com> Date: Thu, 12 Dec 2019 12:26:41 -0600 In-Reply-To: (Arnd Bergmann's message of "Wed, 11 Dec 2019 20:31:28 +0100") Message-ID: <87zhfxqu1q.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1ifTBV-0007Vb-8k; ; ; mid=<87zhfxqu1q.fsf@x220.int.ebiederm.org>; ; ; hst=in01.mta.xmission.com; ; ; ip=68.227.160.95; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX18Nj1okHY+lVK9nVgaeSq2QimrMTWlLlGo= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 12/22] arm64: mte: Add specific SIGSEGV codes 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) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191212_102820_517010_4A1855C3 X-CRM114-Status: GOOD ( 16.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , Richard Earnshaw , Szabolcs Nagy , Catalin Marinas , Kevin Brodsky , Andrey Konovalov , Linux-MM , Al Viro , Marc Zyngier , Vincenzo Frascino , Will Deacon , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Arnd Bergmann writes: > On Wed, Dec 11, 2019 at 7:40 PM Catalin Marinas wrote: >> >> From: Vincenzo Frascino >> >> Add MTE-specific SIGSEGV codes to siginfo.h. >> >> Note that the for MTE we are reusing the same SPARC ADI codes because >> the two functionalities are similar and they cannot coexist on the same >> system. Please Please Please don't do that. It is actively harmful to have architecture specific si_code values. As it makes maintenance much more difficult. Especially as the si_codes are part of union descrimanator. If your functionality is identical reuse the numbers otherwise please just select the next numbers not yet used. We have at least 256 si_codes per signal 2**32 if we really need them so there is no need to be reuse numbers. The practical problem is that architecture specific si_codes start turning kernel/signal.c into #ifdef soup, and we loose a lot of basic compile coverage because of that. In turn not compiling the code leads to bit-rot in all kinds of weird places. Now as far as the observation that this is almost the same as other functionality why can't this fit the existing interface exposed to userspace? Sometimes there are good reasons, but technology gets a lot more uptake and testing when the same interfaces are more widely available. Eric p.s. As for coexistence there is always the possibility that one chip in a cpu family does supports one thing and another chip in a cpu family supports another. So userspace may have to cope with the situation even if an individual chip doesn't. I remember a similar case where sparc had several distinct page table formats and we had a single kernel that had to cope with them all. >> Cc: Arnd Bergmann >> Signed-off-by: Vincenzo Frascino >> [catalin.marinas@arm.com: renamed precise/imprecise to sync/async] >> Signed-off-by: Catalin Marinas >> --- >> include/uapi/asm-generic/siginfo.h | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h >> index cb3d6c267181..a5184a5438c6 100644 >> --- a/include/uapi/asm-generic/siginfo.h >> +++ b/include/uapi/asm-generic/siginfo.h >> @@ -227,8 +227,13 @@ typedef struct siginfo { >> # define SEGV_PKUERR 4 /* failed protection key checks */ >> #endif >> #define SEGV_ACCADI 5 /* ADI not enabled for mapped object */ >> -#define SEGV_ADIDERR 6 /* Disrupting MCD error */ >> -#define SEGV_ADIPERR 7 /* Precise MCD exception */ >> +#ifdef __aarch64__ >> +# define SEGV_MTEAERR 6 /* Asynchronous MTE error */ >> +# define SEGV_MTESERR 7 /* Synchronous MTE exception */ >> +#else >> +# define SEGV_ADIDERR 6 /* Disrupting MCD error */ >> +# define SEGV_ADIPERR 7 /* Precise MCD exception */ >> +#endif > > SEGV_ADIPERR/SEGV_ADIDERR were added together with SEGV_ACCADI, > it seems a bit odd to make only two of them conditional but not the others. > > I think we are generally working towards having the same constants > across architectures even for features that only exist on one of them. > > Adding Al and Eric to Cc, maybe they have another suggestion on what > constants should be used. > > Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel