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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 39BC5C83000 for ; Tue, 28 Apr 2020 13:43:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DAEA3206D6 for ; Tue, 28 Apr 2020 13:43:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAEA3206D6 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 357588E0005; Tue, 28 Apr 2020 09:43:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 308448E0001; Tue, 28 Apr 2020 09:43:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F6C78E0005; Tue, 28 Apr 2020 09:43:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 046C08E0001 for ; Tue, 28 Apr 2020 09:43:06 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id ABBC98248D51 for ; Tue, 28 Apr 2020 13:43:06 +0000 (UTC) X-FDA: 76757379972.24.week08_38357b750a134 X-HE-Tag: week08_38357b750a134 X-Filterd-Recvd-Size: 3930 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Apr 2020 13:43:06 +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 42A0431B; Tue, 28 Apr 2020 06:43:05 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A0EC03F68F; Tue, 28 Apr 2020 06:43:03 -0700 (PDT) Date: Tue, 28 Apr 2020 14:43:01 +0100 From: Catalin Marinas To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, Richard Earnshaw , Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , Peter Collingbourne , linux-mm@kvack.org, Vincenzo Frascino , Will Deacon Subject: Re: [PATCH v3 10/23] arm64: mte: Handle synchronous and asynchronous tag check faults Message-ID: <20200428134301.GI3868@gaia> References: <20200421142603.3894-1-catalin.marinas@arm.com> <20200421142603.3894-11-catalin.marinas@arm.com> <20200427165822.GE15808@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200427165822.GE15808@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 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. > > 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). Thanks. -- Catalin