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=-8.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 08868C55199 for ; Mon, 27 Apr 2020 16:58:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8A68206D9 for ; Mon, 27 Apr 2020 16:58:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8A68206D9 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 6D6248E0005; Mon, 27 Apr 2020 12:58:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6871B8E0001; Mon, 27 Apr 2020 12:58:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C4578E0005; Mon, 27 Apr 2020 12:58:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 44BE78E0001 for ; Mon, 27 Apr 2020 12:58:27 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0408382499A8 for ; Mon, 27 Apr 2020 16:58:27 +0000 (UTC) X-FDA: 76754243454.22.waves47_66d6eec1adf20 X-HE-Tag: waves47_66d6eec1adf20 X-Filterd-Recvd-Size: 4453 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Apr 2020 16:58:26 +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 A236031B; Mon, 27 Apr 2020 09:58:25 -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 38C633F68F; Mon, 27 Apr 2020 09:58:24 -0700 (PDT) Date: Mon, 27 Apr 2020 17:58:22 +0100 From: Dave Martin To: Catalin Marinas 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: <20200427165822.GE15808@arm.com> References: <20200421142603.3894-1-catalin.marinas@arm.com> <20200421142603.3894-11-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421142603.3894-11-catalin.marinas@arm.com> 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 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. > Signed-off-by: Vincenzo Frascino > Co-developed-by: Catalin Marinas > Signed-off-by: Catalin Marinas > Cc: Will Deacon [...] > 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. If MTEAERR is forced, a martian tag check failure might land in the middle of a "normal" SIGSEGV, when SIGSEGV would usually be blocked for good reasons, defeating the process' own handling mechanisms for no good reason: delivering the MTEAERR when SIGSEGV is next unblocked seems perfectly reasonable in such a case. Only braindead software would block or ignore things like SIGSEGV across exec, so software shouldn't end up ignoring these non-forced signals unless it does so on purpose. Alternatively, perhaps asynchronous errors should be delivered via a different signal. I don't have a good suggestion though. [...] Cheers ---Dave