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=-10.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,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 78912C4743C for ; Mon, 21 Jun 2021 12:41:21 +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 4C9166101D for ; Mon, 21 Jun 2021 12:41:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C9166101D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=t8f3m1EGYBxYiSHfFnR8r58R5k3vSbSUHqAMRCHte7Q=; b=uT4/kPpfQ2c7NY sjlG6MldBH102luNHwPLoszmYPXsTFph2YZWNAfdn8gtndd2IJ+KCmY+Nl+6/bey1RsDC2Jv5tHJu wxzEuKPVAb8Y92gfR7MtspYyeOOvbTUsZWvybSAjjRMuawmSEbXaq+tThozb2j9yvY54pC1U6IZwS k0s00yzv7ERinuBH8kvLZMbFHBaSQISQoKLY4cvv5ZgRE2jJom0uHYJUa27YlwR2GtVhIH9O3NL48 u9iU5r0/UnxVN7uywEDek7M3XzznmTAgNMr/BrYge4HUwXTYV7+UXlJe0PYvhYjqdYfDGiERieYmC v0S2qge1LEEb054yJKcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvJDO-003UW1-HX; Mon, 21 Jun 2021 12:39:46 +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 1lvJDK-003UVY-9l for linux-arm-kernel@lists.infradead.org; Mon, 21 Jun 2021 12:39:43 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B852460FF4; Mon, 21 Jun 2021 12:39:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624279181; bh=Iq8ITjhpTjwxg28XVHdbrqnJMHv/35Gb4VBe/gFv6ZM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RGJCYzls6LWLPbqV8QFExgu3WOhZVoeJe5sm8F3nB+9+HA0VmGcMY5mLGhWNufpAL 8SXRlPbWo+oHjMtHguesC0G621YZactB+f8XUtfcn/uiYnsBH47ofB5enjkjnYd9jP 6Dv3ZbN+yfiCj4mWiMLs5ex94NbgewKL+YN3jhCOZp5hxWxCDU0nZuAGpmnDOu6x8d ppmFzHst38/zdpBgyaYIAmCf7MLyiYG+1BKAX7oPxVbIXNGpwkfFHWvMoVsp64PED2 Gi5dPjR7qhIix4ZRQP3D9jRzgdcr+6X15MXd2Dm6CcoK6FzayPkO1sx9FhUCY0onne sZiC804WGN8rw== Date: Mon, 21 Jun 2021 13:39:37 +0100 From: Will Deacon To: Catalin Marinas Cc: Peter Collingbourne , Vincenzo Frascino , Evgenii Stepanov , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis Message-ID: <20210621123936.GB29283@willie-the-truck> References: <20210615203807.3582804-1-pcc@google.com> <20210617215829.GD25403@willie-the-truck> <20210618150953.GH16116@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210618150953.GH16116@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-20210621_053942_423875_A240F19B X-CRM114-Status: GOOD ( 33.75 ) 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 Fri, Jun 18, 2021 at 04:09:55PM +0100, Catalin Marinas wrote: > On Thu, Jun 17, 2021 at 10:58:30PM +0100, Will Deacon wrote: > > On Tue, Jun 15, 2021 at 01:38:07PM -0700, Peter Collingbourne wrote: > > > +Upgrading to stricter tag checking modes > > > +---------------------------------------- > > > + > > > +On some CPUs the performance of MTE in stricter tag checking modes > > > +is similar to that of less strict tag checking modes. This makes it > > > +worthwhile to enable stricter checks on those CPUs when a less strict > > > +checking mode is requested, in order to gain the error detection > > > +benefits of the stricter checks without the performance downsides. To > > > +opt into upgrading to a stricter checking mode on those CPUs, the user > > > +can set the ``PR_MTE_DYNAMIC_TCF`` flag bit in the ``flags`` argument > > > +to the ``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call. > > > + > > > +This feature is currently only supported for upgrading from > > > +asynchronous mode. To configure a CPU to upgrade from asynchronous mode > > > +to synchronous mode, a privileged user may write the value ``1`` to > > > +``/sys/devices/system/cpu/cpu/mte_upgrade_async``, and to disable > > > +upgrading they may write the value ``0``. By default the feature is > > > +disabled on all CPUs. > > > + > > > Initial process state > > > --------------------- > > > > > > @@ -128,6 +147,7 @@ On ``execve()``, the new process has the following configuration: > > > - ``PR_TAGGED_ADDR_ENABLE`` set to 0 (disabled) > > > - Tag checking mode set to ``PR_MTE_TCF_NONE`` > > > - ``PR_MTE_TAG_MASK`` set to 0 (all tags excluded) > > > +- ``PR_MTE_DYNAMIC_TCF`` set to 0 (disabled) > > > - ``PSTATE.TCO`` set to 0 > > > - ``PROT_MTE`` not set on any of the initial memory maps > > > > Something about this doesn't sit right with me, as we're mixing a per-task > > interface with a per-cpu interface for selecting async/sync MTE and the > > priorities are somewhat confusing. > > > > I think a better interface would be for the sysfs entry for each CPU to > > allow selection between: > > > > task : Honour the prctl() (current behaviour) > > async : Force async for tasks using MTE > > sync : Force sync for tasks using MTE > > none : MTE disabled > > > > i.e. the per-cpu setting is an override. > > As Peter mentioned, forcing it is a potential ABI break, so such feature > would need backporting to 5.10. There's also a minor use-case that came > up in the early discussions - an app may want to use async mode only for > reporting but forcing it to sync would break such application (since > sync mode prevents the faulty access from taking place). Why is it an ABI break? The default will be "task" which behaves exactly as things do today. If the policy is explicitly changed by userspace, then you get new behaviour. I don't really see why this is different to e.g. writing /proc/sys/vm/mmap_min_addr and having some applications fail because they rely on the default setting. > So I'd rather leave it up to the user task to decide whether its choice > can be changed. Peter introduced a new PR_MTE_DYNAMIC_TCF for this > purpose (or a different name if you have a better suggestion). I don't see how PR_MTE_DYNAMIC_TCF is useful to userspace, really. It's an extra bit of logic to go and set it, but then what? It doesn't know which behaviour it's getting, so it just feels like an extra hoop to jump through without actually adding anything useful. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel