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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 96D22C2B9F4 for ; Mon, 14 Jun 2021 18:27:16 +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 4D9C7611EE for ; Mon, 14 Jun 2021 18:27:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D9C7611EE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xk0Hb8ZQdeRBdyfUUjhD8u+84CRHA98AEoHtnnUsuJg=; b=db+72aLVW9A9hA V2gneDUYgcMpMkYV/dPUqQxhwH1may5WUMxqZZiCZhJ7kXqSSFP7r9mX7ARUA8ujwnt6BOLxfn+/E F1Ju6KrBtKMBdQekBXYQyscoW8P8M9ev1cU6M7Z5c252q499RPf+GGAvazHjTRcYXIY3Dg9dZae0p ESZd5UKZdFQDIe+5dIAh9zynMnPg6or7Rtht7AP0Br5i4kAB1Knz4jrFmiuS3EJjs4hgFCr/SRgMx qovdRCksfUKWd/igp4OBN80TRxFreW02hG/vOHrOHz+PfqbjgUF/I2jRIM4ImNs+iHh8Y583NAfP5 8pWl7biOrX104o3tWTjQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsrHD-00Fi9t-Tl; Mon, 14 Jun 2021 18:25:36 +0000 Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsrH8-00Fi8K-Ku for linux-arm-kernel@lists.infradead.org; Mon, 14 Jun 2021 18:25:32 +0000 Received: by mail-io1-xd31.google.com with SMTP id l64so19001857ioa.7 for ; Mon, 14 Jun 2021 11:25:29 -0700 (PDT) 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=cITEwL608QGbEp5EArwa4R8bVlbZet4bgn6yxGyR2kw=; b=AycmgBWA/jI8azBfdykYOCnXIezMf54EA2oKSQrUWptmtQz1ixvUj+vpjGhIJj9I6p Fi7oC/YPdCDAiI7DNbSVQodVOMIT2qlRkSgZGkEdCvcToPlg9pW8KVxuqGB9HpnNZ8K4 8NmU8eyUwK/hZc8mHHXPuVq5Qj2w0FyRzSTv9WBCox5Q484lKbG1dXPt2A/pebckN2tW 5APOJDbcyCvVdJ/ANs38v6hViRnNj1cMq1TeQDdSAvZt9ryu3pS0EKTs5KuCwv5H4imx RCmjfAZ66Al8wXVcopBVBu0HfE4hZsoMoExuTq3OvSWa+7StJp3Xa94qJAxwqdUHU9mt eAug== 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=cITEwL608QGbEp5EArwa4R8bVlbZet4bgn6yxGyR2kw=; b=cQfckPY7ujIEes7/2KeWz6QdvCKx4+S8HMspBq+JQqBWrpttFBM8q3WdIh7CJ4pM/Z Rcw++1AlZXnDdt8GSHrgBsq5TRsWkg09S963ZAHsTCkxi+IXGe1CRXtOIjltnFV+UWOz sU0BgsUgml53QP8jJ6+y4emM5ZiFuxjUQ2y/6o46PkoxNs98fqv1JHGWR4nYGnNBUfAK 1bTF4fDZrfb/ZRVX9XmRpFvXD7I5+Sy25iulmEZJYhKbA1n/d3tdpfTy0T50ulhejJag ccGrBpOA2gusVvaZJnR/aPCvOfa1TB59IFEkS5kjFMu66F0GHmK3L4Rfygo/iBl8x0Fw P5GA== X-Gm-Message-State: AOAM533PqsOyQA9xWBuvYzG5bNLDIBYWp0FMWkiQNBTouA4GwCB+4TFt zrUa+QXLTV9+c901kdtlwU6N1KR0nocbHWcKKVTWOQ== X-Google-Smtp-Source: ABdhPJzD6Yu0hGUA7YwiKJLOXNfqg6pEf9ooYXf97WPz1oqDxgCY/qrELR+K9h9iOj5IXUtDTFaWRZGXh6fqxNFYnCI= X-Received: by 2002:a5e:8349:: with SMTP id y9mr15114372iom.105.1623695129141; Mon, 14 Jun 2021 11:25:29 -0700 (PDT) MIME-Version: 1.0 References: <20210610021229.3605241-1-pcc@google.com> <20210611144915.GE8132@arm.com> <20210614173748.GH30667@arm.com> In-Reply-To: <20210614173748.GH30667@arm.com> From: Peter Collingbourne Date: Mon, 14 Jun 2021 11:25:17 -0700 Message-ID: Subject: Re: [PATCH v2] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis To: Catalin Marinas Cc: Vincenzo Frascino , Will Deacon , Evgenii Stepanov , Linux ARM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210614_112530_719767_DE6DE75F X-CRM114-Status: GOOD ( 42.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 14, 2021 at 10:37 AM Catalin Marinas wrote: > > On Fri, Jun 11, 2021 at 02:50:03PM -0700, Peter Collingbourne wrote: > > On Fri, Jun 11, 2021 at 7:49 AM Catalin Marinas wrote: > > > On Wed, Jun 09, 2021 at 07:12:29PM -0700, Peter Collingbourne wrote: > > > > diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h > > > > index 9df3feeee890..545ef900e7ce 100644 > > > > --- a/arch/arm64/include/asm/processor.h > > > > +++ b/arch/arm64/include/asm/processor.h > > > > @@ -159,6 +159,7 @@ struct thread_struct { > > > > #define SCTLR_USER_MASK \ > > > > (SCTLR_ELx_ENIA | SCTLR_ELx_ENIB | SCTLR_ELx_ENDA | SCTLR_ELx_ENDB | \ > > > > SCTLR_EL1_TCF0_MASK) > > > > +#define SCTLR_USER_DYNAMIC_TCF (1ULL << 63) > > > > > > Even if you called it "USER", it still gives the impression that it's > > > some real hardware bit. Who knows, in a few years time it may be > > > allocated to a real feature. > > > > If bit 63 ends up being allocated to a bit that we want to allow > > userspace control over then we can always just move this to another > > bit. There are plenty to choose from that I don't think we will ever > > allow user control over, e.g. EIS. > > > > > I also don't think this logic should be added to processor.[ch], just > > > keep it within mte.c. > > > > > > So while it's convenient to add something to this field, given that it's > > > shared with ptrauth, it's pretty fragile long term. I'd add the > > > information about the dynamic mode to a different field. We could rename > > > gcr_user_excl to mte_ctrl or something and store a few bits in there in > > > addition to GCR_EL1.Excl (with corresponding masks etc.) > > > > I do take your point that it's somewhat awkward to commingle the SCTLR > > bits and the dynamic TCF setting here, but I'm not sure that it's > > overall better to move the bits to a renamed gcr_user_excl field. The > > consequence would be that we need two copies of the TCF setting in > > thread_struct and they will need to be kept in sync and leads to an > > implicit ordering dependency between the code dealing with the two > > fields on context switch. > > I haven't checked v3 yet but I don't understand what the ordering > problem is. gcr_user_excl is also part of thread_struct and it shouldn't > change while the thread is in the middle of a context switch. It's not due to multithreading but more to do with making the code less readable by adding constraints on the code, i.e. with your scheme the call to mte_thread_switch() would implicitly need to happen before update_sctlr_el1() whereas there was no such constraint before. > > We can make this more maintainable by adding a static_assert that > > SCTLR_USER_DYNAMIC_TCF doesn't overlap with any of the bits in > > SCTLR_USER_MASK, as I've done in v3. > > > > Let me know what you think and if you still disagree then I can try to > > make this look more like you suggested. > > I just don't like adding software bits to the sctlr field. Who knows, we > may need to add some more for MTE, maybe other features would do > something similar and it's not maintainable. Oh, that's unfortunate. As you might imagine I still disagree that it's less maintainable but I guess it's not too important so I'll change the code as you requested. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel