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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 6E6AAC11F65 for ; Wed, 30 Jun 2021 15:20:57 +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 24CDB61476 for ; Wed, 30 Jun 2021 15:20:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24CDB61476 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=fq9Ou9gyPAukyfqYNyusrjFcwvT4Akb+Fktk6WBtfvw=; b=zS6LLHuLkv//zg 9P9929rZEyUXw/9oocQRnXJ6v26pOCewRZp0vtYD+3vWFJOb3EHjsG9YjQSkU/sRzp45KwNqCq/W6 ShCAD8AQrBzrgKTV/AJzM7wyzZDfhBBDClZvRK7HUYybW9FxPR9cTwn8goz6A1blMApRRmgm4vO02 k4CqnC8kt3bbisi4D7OegjJu1GEg0yMD46aPuE+v+3jm8RU/jeAUG7JwlMHrkSXvhTDSokOvCyfpu 5Qtofv2Q6O3vkIpX/qlJCxKOgGRh6lSWCSd82HguZf+hKvtXOdz7M6QSdpCgwJn/0QG+OYAMVXXap /MBHf8DigEuKZkFbYC/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lybzi-00EbzC-ED; Wed, 30 Jun 2021 15:19:18 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lybzb-00EbyS-Gt for linux-arm-kernel@lists.infradead.org; Wed, 30 Jun 2021 15:19:16 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C8490613EF; Wed, 30 Jun 2021 15:19:09 +0000 (UTC) Date: Wed, 30 Jun 2021 16:19:07 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Will Deacon , Szabolcs Nagy , Vincenzo Frascino , Evgenii Stepanov , Linux ARM , Tejas Belagod Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis Message-ID: <20210630151906.GD3426@arm.com> References: <20210623085530.GF13058@arm.com> <20210624165228.GB25097@arm.com> <20210625092253.GJ13058@arm.com> <20210625120137.GC20835@arm.com> <20210625123959.GB3170@willie-the-truck> <20210625135350.GD20835@arm.com> <20210628101448.GA5503@willie-the-truck> <20210628152023.GA9308@arm.com> <20210629104625.GA7168@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20210630_081911_634483_1717BEEE X-CRM114-Status: GOOD ( 38.72 ) 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 Tue, Jun 29, 2021 at 12:11:17PM -0700, Peter Collingbourne wrote: > On Tue, Jun 29, 2021 at 3:46 AM Will Deacon wrote: > > On Mon, Jun 28, 2021 at 04:20:24PM +0100, Catalin Marinas wrote: > > > Another option is a mapping table where async can be remapped to sync > > > and sync to async (or even to "none" for both). That's not far from one > > > of Peter's mte-upgrade-async proposal, we just add mte-map-async and > > > mte-map-sync options. Most likely we'll just use mte-map-async for now > > > to map it to sync on some CPUs but it wouldn't exclude other forced > > > settings. > > > > Catalin and I discussed this offline and ended up with another option: > > retrospectively change the prctl() ABI so that the 'flags' argument > > accepts a bitmask of modes that the application is willing to accept. This > > doesn't break any existing users, as we currently enforce that only one > > mode is specified, but it would allow things like: > > > > prctl(PR_SET_TAGGED_ADDR_CTRL, > > PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC, > > 0, 0, 0); > > > > which is actually very similar to Peter's PR_MTE_DYNAMIC_TCF proposal, with > > the difference that I think this extends more naturally as new PR_MTR_TCF_* > > flags are introduced. > > > > Then we expose a per-cpu file in sysfs (say "cpuX/mte_tcf_preferred") > > which initially reads as "async". If the root user does, e.g. > > > > # echo "sync" > cpu1/mte_tcf_preferred > > > > then a task which has successfully issued a PR_SET_TAGGED_ADDR_CTRL prctl() > > request for PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC will run in sync mode on > > CPU1, but async mode on other CPUs (assuming they retain the default value). > > > > We'll need to special-case PR_MTE_TCF_NONE, as that's just a shorthand for > > "no flags" so doing PR_MTE_TCF_NONE | PR_MTE_TCF_SYNC is just the same as > > doing PR_MTE_TCF_SYNC (which I think is already the behaviour today). The > > only values which the sysfs files would accept today are "sync" and "async". > > > > When faced with a situation where the prctl() flags for a task do not > > intersect with the preferred mode for a CPU on which the task is going > > to run, the lowest bit number flag is chosen from the mask set by the > > prctl(). > > > > Thoughts? > > This all sounds great and I'm glad you were able to come to an > agreement on this. I'll get started on implementing it. > > Once we have ASYM support I'm not sure if we can rely on bit numbering > for ordering, as we will want the ordering to be ASYNC < ASYM < SYNC > and ASYNC is bit-adjacent to SYNC. So I think we will need to make > ASYM a special case. The bit position based order - SYNC < ASYNC < ASYM - is indeed arbitrary but I think it's easier to follow. When we add ASYM, it will be the last one rather than squeezing it in the middle of the current order. Any other order somehow implies that one is better than the other but we don't have a clear definition for "better". > This would also allow NONE to be upgraded by allocating a bit position > for NONE, but if we change the value of NONE it may break applications > built against new headers running on old kernels, so maybe it should > be made a separate constant. This doesn't need to be done immediately, > though. I think we should leave NONE as non-upgradable, the software doesn't expect any fault when accessing with the wrong tag. We also can't change the definition now as it's already in upstream glibc. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel