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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E8464C83000 for ; Tue, 28 Apr 2020 13:43:10 +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 9E546206D7 for ; Tue, 28 Apr 2020 13:43:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mMHd6kMT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E546206D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+hwGvHFPLgvM+izZXnmYHJUsp25z3Mt92J5a+c5unm0=; b=mMHd6kMTlSYZeA XsVBPldOEsmRDYZBxFG8zjk0IuADedMTmuqhJSkPFfdH9REkYTSZ/MToPz+DMnFxxW9E/OtSFIGnx fmFFmp9wZKCChKX1Y9Nf85lsM96XcxMqtnO3MB2/AlLthD6w8WH05nVZQJ8kodUOUnOAfNYXU4KZe BZA8oWsO9Pms25bzZIhND8eZsNY/GPEoCHV2qu4ZZods4OuFt8sOUPLHWQssVyg3AH0xVaIur//Et 32sZMX2JKNSWBjdLxb3b4WeLweAlp98TUU6ws5SfkAw0tD206sSR98xbjSXaNkNB6W2Ye6uSbo3Pr uDnIvcbZLKFWmo0Wahtg==; 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 1jTQVx-0008Ew-S5; Tue, 28 Apr 2020 13:43:09 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTQVu-0008E5-0U for linux-arm-kernel@lists.infradead.org; Tue, 28 Apr 2020 13:43:07 +0000 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 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-Disposition: inline In-Reply-To: <20200427165822.GE15808@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200428_064306_101869_34FA732B X-CRM114-Status: GOOD ( 21.29 ) 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@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 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel