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=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 DB6D9C34031 for ; Tue, 18 Feb 2020 22:00:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 676A321D56 for ; Tue, 18 Feb 2020 22:00:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="nreTZoRp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 676A321D56 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E73F96B0005; Tue, 18 Feb 2020 17:00:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E25776B0006; Tue, 18 Feb 2020 17:00:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D147D6B0007; Tue, 18 Feb 2020 17:00:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id B9AD46B0005 for ; Tue, 18 Feb 2020 17:00:10 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8A4A9180AD81D for ; Tue, 18 Feb 2020 22:00:10 +0000 (UTC) X-FDA: 76504616580.01.month12_1e9152ed6ff0a X-HE-Tag: month12_1e9152ed6ff0a X-Filterd-Recvd-Size: 6565 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 22:00:09 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id n10so23884907wrm.1 for ; Tue, 18 Feb 2020 14:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RXQHJwHEEnVHauBnQEp+K06dMcddSWeFIBEKwcqNjvY=; b=nreTZoRpOvqTwmumvsIXMrFVOQXcDbnv6W15HbKXapZS3n8EE++vulDuWNS626JKXw +zgAgLRoc6fC6Il9RExWb4VJrWYxeW9A3UWfjSLrUx417GidXbEIcvyt6DOW901H8KG8 DiNoEwck1n/rwqtQ7ihZ0svt7RwwHRNHDwpmVdmUUUA40GjEvFcDcb9FkeuzTSiyzL81 ccvxaeOFJ9URflRugRrRHN4FbYbQg2rBsn1R5N2O2PLq4xuXt4kzQfRvD/QBS3bbaoOg JsFkoI4Ejjtrng4tW/kSPuVNJ4IJ7HsjxshWOcGGeQ4LNLmP8r2hE3bJ27FuwV7azSJ2 kpbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RXQHJwHEEnVHauBnQEp+K06dMcddSWeFIBEKwcqNjvY=; b=Jm/0E/LkuKVmfRjzPRNEmeFa2CdEbhihNzku1lR0mDu03akGl2fh+eBBCCTpW78xBK tJdxTtsdclU2vnMc+gTMFlP9L+rtbEFwukSyaAl+PoYrLH7YNLi3ejUDxmTDUhIQBpXq TQIfqkg4ZHURNTcrmIZNtFnqwoFptptXeA/DJBLcxBW444q84pE+od6WvGff7BHe+swR 5cXj4/aF5h23RV6IUUs1BZF7rWYZkOOyV0wdG3mhzPkpox7YkNB52Gm4BdRqB81z4X0P 0ncTfSbuvmrVC+FBrFPSUBV2NcmoRG9KpxmqLtsDHC9z+1ZIWveZBq0P8hOuC/eHmJwi ++fw== X-Gm-Message-State: APjAAAWMKLEBP5t3QLBEYfo/Hc7+NfkH6ObsNyXWzgkWMGWJ0u3O0zUW C29aZWnvcn67I9ybR+z04pdd3cxu2N9kP2GLPfD8/w== X-Google-Smtp-Source: APXvYqy6irBj57I3FWNNO68AlkFwJP+eCW7WSFRMfNtH7vP/kn7OPj/7/NLtMwqMwPtdUdZ5NYhKCB5JRZmiRVLY0As= X-Received: by 2002:adf:e40f:: with SMTP id g15mr30563070wrm.223.1582063187500; Tue, 18 Feb 2020 13:59:47 -0800 (PST) MIME-Version: 1.0 References: <20191217180152.GO5624@arrakis.emea.arm.com> <20191220013639.212396-1-pcc@google.com> <20200212110903.GE488264@arrakis.emea.arm.com> In-Reply-To: <20200212110903.GE488264@arrakis.emea.arm.com> From: Peter Collingbourne Date: Tue, 18 Feb 2020 13:59:34 -0800 Message-ID: Subject: Re: [PATCH] arm64: mte: Do not service syscalls after async tag fault To: Catalin Marinas Cc: Evgenii Stepanov , Kostya Serebryany , Linux ARM , linux-arch@vger.kernel.org, Richard Earnshaw , Szabolcs Nagy , Marc Zyngier , Kevin Brodsky , linux-mm@kvack.org, Andrey Konovalov , Vincenzo Frascino , Will Deacon Content-Type: text/plain; charset="UTF-8" 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 Wed, Feb 12, 2020 at 3:09 AM Catalin Marinas wrote: > > On Thu, Dec 19, 2019 at 05:36:39PM -0800, Peter Collingbourne wrote: > > When entering the kernel after an async tag fault due to a syscall, rather > > than for another reason (e.g. preemption), we don't want to service the > > syscall as it may mask the tag fault. Rewind the PC to the svc instruction > > in order to give a userspace signal handler an opportunity to handle the > > fault and resume, and skip all other syscall processing. > > > > Signed-off-by: Peter Collingbourne > > --- > [...] > > arch/arm64/kernel/syscall.c | 22 +++++++++++++++++++--- > > 1 file changed, 19 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c > > index 9a9d98a443fc..49ea9bb47190 100644 > > --- a/arch/arm64/kernel/syscall.c > > +++ b/arch/arm64/kernel/syscall.c > > @@ -95,13 +95,29 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, > > { > > unsigned long flags = current_thread_info()->flags; > > > > - regs->orig_x0 = regs->regs[0]; > > - regs->syscallno = scno; > > - > > cortex_a76_erratum_1463225_svc_handler(); > > local_daif_restore(DAIF_PROCCTX); > > user_exit(); > > > > +#ifdef CONFIG_ARM64_MTE > > + if (flags & _TIF_MTE_ASYNC_FAULT) { > > + /* > > + * We entered the kernel after an async tag fault due to a > > + * syscall, rather than for another reason (e.g. preemption). > > + * In this case, we don't want to service the syscall as it may > > + * mask the tag fault. Rewind the PC to the svc instruction in > > + * order to give a userspace signal handler an opportunity to > > + * handle the fault and resume, and skip all other syscall > > + * processing. > > + */ > > + regs->pc -= 4; > > + return; > > + } > > +#endif > > + > > + regs->orig_x0 = regs->regs[0]; > > + regs->syscallno = scno; > > I'm slightly worried about the interaction with single-step, other > signals. It might be better if we just use the existing syscall > restarting mechanism. Untested diff below: > > -------------------8<------------------------------- > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c > index a12c0c88d345..db25f5d6a07c 100644 > --- a/arch/arm64/kernel/syscall.c > +++ b/arch/arm64/kernel/syscall.c > @@ -102,6 +102,16 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, > local_daif_restore(DAIF_PROCCTX); > user_exit(); > > + if (system_supports_mte() && (flags & _TIF_MTE_ASYNC_FAULT)) { > + /* > + * Process the asynchronous tag check fault before the actual > + * syscall. do_notify_resume() will send a signal to userspace > + * before the syscall is restarted. > + */ > + regs->regs[0] = -ERESTARTNOINTR; > + return; > + } > + > if (has_syscall_work(flags)) { > /* set default errno for user-issued syscall(-1) */ > if (scno == NO_SYSCALL) That works for me, and I verified that my small test program as well as some larger unit tests behave as expected. Tested-by: Peter Collingbourne Peter