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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 CDF02C83004 for ; Wed, 29 Apr 2020 10:26:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 98CD22073E for ; Wed, 29 Apr 2020 10:26:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98CD22073E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 470168E0007; Wed, 29 Apr 2020 06:26:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4208C8E0001; Wed, 29 Apr 2020 06:26:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3366B8E0007; Wed, 29 Apr 2020 06:26:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id 1BECA8E0001 for ; Wed, 29 Apr 2020 06:26:33 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CF324180AD804 for ; Wed, 29 Apr 2020 10:26:32 +0000 (UTC) X-FDA: 76760513424.18.grass20_90701ede89f10 X-HE-Tag: grass20_90701ede89f10 X-Filterd-Recvd-Size: 4301 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Apr 2020 10:26:32 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ADEBDC14; Wed, 29 Apr 2020 03:26:31 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 445393F73D; Wed, 29 Apr 2020 03:26:30 -0700 (PDT) Date: Wed, 29 Apr 2020 11:26:28 +0100 From: Dave Martin To: Catalin Marinas Cc: linux-arch@vger.kernel.org, Richard Earnshaw , Will Deacon , Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , linux-mm@kvack.org, Vincenzo Frascino , Peter Collingbourne , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 10/23] arm64: mte: Handle synchronous and asynchronous tag check faults Message-ID: <20200429102628.GB30377@arm.com> References: <20200421142603.3894-1-catalin.marinas@arm.com> <20200421142603.3894-11-catalin.marinas@arm.com> <20200427165822.GE15808@arm.com> <20200428134301.GI3868@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200428134301.GI3868@gaia> User-Agent: Mutt/1.5.23 (2014-03-12) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 28, 2020 at 02:43:01PM +0100, Catalin Marinas wrote: > On Mon, Apr 27, 2020 at 05:58:22PM +0100, Dave P Martin wrote: > > On Tue, Apr 21, 2020 at 03:25:50PM +0100, Catalin Marinas wrote: > > > From: Vincenzo Frascino > > > > > > The Memory Tagging Extension has two modes of notifying a tag check > > > fault at EL0, configurable through the SCTLR_EL1.TCF0 field: > > > > > > 1. Synchronous raising of a Data Abort exception with DFSC 17. > > > 2. Asynchronous setting of a cumulative bit in TFSRE0_EL1. > > > > > > Add the exception handler for the synchronous exception and handling of > > > the asynchronous TFSRE0_EL1.TF0 bit setting via a new TIF flag in > > > do_notify_resume(). > > > > > > On a tag check failure in user-space, whether synchronous or > > > asynchronous, a SIGSEGV will be raised on the faulting thread. > > > > Has there been any discussion on whether this should be SIGSEGV or > > SIGBUS? > > > > Probably neither is much more appropriate than the other. > > You could argue either way. I don't recall a firm conclusion on this, so > I picked one that follows SPARC ADI. Agreed, that precedent is good enough for me. I hadn't refreshed my memory of how sparc was using these signals. > > > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c > > > index 339882db5a91..e377d77c065e 100644 > > > --- a/arch/arm64/kernel/signal.c > > > +++ b/arch/arm64/kernel/signal.c > > > @@ -732,6 +732,9 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka, > > > regs->regs[29] = (unsigned long)&user->next_frame->fp; > > > regs->pc = (unsigned long)ka->sa.sa_handler; > > > > > > + /* TCO (Tag Check Override) always cleared for signal handlers */ > > > + regs->pstate &= ~PSR_TCO_BIT; > > > + > > > if (ka->sa.sa_flags & SA_RESTORER) > > > sigtramp = ka->sa.sa_restorer; > > > else > > > @@ -923,6 +926,11 @@ asmlinkage void do_notify_resume(struct pt_regs *regs, > > > if (thread_flags & _TIF_UPROBE) > > > uprobe_notify_resume(regs); > > > > > > + if (thread_flags & _TIF_MTE_ASYNC_FAULT) { > > > + clear_thread_flag(TIF_MTE_ASYNC_FAULT); > > > + force_signal_inject(SIGSEGV, SEGV_MTEAERR, 0); > > > + } > > > + > > > > Should this definitely be a force_signal_inject()? > > > > SEGV_MTEAERR is not intrinsically fatal: it must be possible to run past > > the error, because that's the whole point -- chances are we already did. > > > > Compare this with MTESERR where running past the signal would lead to a > > spin. > > Good point. This can be a send_sig_fault() (I need to check the right > API). Sounds fair. Cheers ---Dave