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.6 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 CF4B2C2B9F4 for ; Mon, 28 Jun 2021 15:21:56 +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 9A4EE61492 for ; Mon, 28 Jun 2021 15:21:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A4EE61492 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=1uzXe7Vo7u4oD/9Nlu2384H6NrNb6WbuOOG6NvNETUI=; b=47xrhA31E5Bq++ WieEtju+1dEvHTpOBKiusSQrhdY22LXEIGawlCvpiEO+dddsFYT5BGgRuV14rdyAQdDjW8Eo2ZbaX dwdFqA9BM4Xzm3Iu7YPN/FTkXY4vjaNY4WL9gCmS6s25qWCD+C6tMnRAk30eWtpzZk9gD9sIOYW6g zutfyDzJwvQ43Els1tZaWawnaOnrQDSkTdHCGnpfz94NjdSnkrlmFd66SVM3bqBpIAb9a2fCOj3Bk EuKbCRInvZXm3LA9r/lwrroFVEabvKuu8NrqQu/nK9D1F5+Wjprnm6trDHD0DrfHP70yyvetnxYtq vp7OW2LN+xw53Dj6AlrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lxt3o-008RBn-C1; Mon, 28 Jun 2021 15:20:32 +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 1lxt3k-008RAv-MG for linux-arm-kernel@lists.infradead.org; Mon, 28 Jun 2021 15:20:30 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id D089861941; Mon, 28 Jun 2021 15:20:26 +0000 (UTC) Date: Mon, 28 Jun 2021 16:20:24 +0100 From: Catalin Marinas To: Will Deacon Cc: Szabolcs Nagy , Peter Collingbourne , 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: <20210628152023.GA9308@arm.com> References: <20210621173902.GA29713@willie-the-truck> <20210621185036.GD11552@arm.com> <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210628101448.GA5503@willie-the-truck> 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-20210628_082028_804070_D3B72788 X-CRM114-Status: GOOD ( 47.50 ) 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 28, 2021 at 11:14:49AM +0100, Will Deacon wrote: > On Fri, Jun 25, 2021 at 02:53:50PM +0100, Catalin Marinas wrote: > > On Fri, Jun 25, 2021 at 01:39:59PM +0100, Will Deacon wrote: > > > On Fri, Jun 25, 2021 at 01:01:37PM +0100, Catalin Marinas wrote: > > > > So we can document that the mode requested by the app is an indication, > > > > the system may change it to another value (and back-port documentation > > > > to 5.10). If we get a request from developers to honour a specific mode, > > > > we can add a new PR_MTE_TCF_EXACT bit or something but it's not > > > > essential we do it now. > > > > > > > > So if we allow the kernel to change the user requested mode (via sysfs), > > > > I think we still have two more issues to clarify: > > > > > > > > 1. Do we allow only "upgrade" (for some meaning of this) or sysfs can > > > > downgrade to a less strict mode. I'd go for upgrade here to a > > > > stricter check as in Peter's patch. > > > > > > > > 2. Should the sysfs upgrade the PR_MTE_TCF_NONE? _MTAG_ENABLE does that, > > > > so I'd say yes. > > > > > > > > Any other thoughts are welcome. > > > > > > As I mentioned before, I think the sysfs interface should offer: > > > > > > "task" : Honour whatever the task has asked for (default) > > > "async" : Force async on this CPU > > > "sync" : Force sync on this CPU > > > > > > I don't think we should upgrade PR_MTE_TCF_NONE unless we also have a "none" > > > option in here. I originally suggested that, but in hindsight it feels like > > > a bad idea because a task could SIGILL on migration. So what we're saying is > > > that PR_MTE_TCF_SYNC and PR_MTE_TCF_ASYNC will always enable MTE on success, > > > but the reporting mode is a hint. > > > > > > I don't think upgrade/downgrade makes a lot of sense given that the sysfs > > > controls can be changed at any point in time. It should just be an override. > > > > The problem with sysfs is that it's global, so it assumes that any > > process has the same needs. The _MTAG_ENABLE glibc tunable at least can > > be set per process. > > Again, this seems to be an argument against doing this at all. We already > have a per-task interface to change the checking mode, but there is a need > to override this on a per-cpu basis to achieve acceptable performance. > Applications can't possibly be aware of that and so their "needs" cannot be > taken into account here. That's because we have two conflicting needs: (a) more precise checking for debugging or increased security and (b) better performance. The sysfs interface is primarily meant for (b) but that overrides any application choice for (a). > > > This means that we can force async for CPUs where sync mode is horribly > > > slow, whilst honouring the task's request on CPUs which are better > > > implemented. > > > > This may hamper debugging on, for example, a system where the root > > configured the modes for CPUs and a normal user wants to use MTE to > > identify access bugs. Another case is some service that wants tightened > > security from MTE irrespective of the performance. > > I suppose the way I see this is similar to how I see CPU errata: essentially > sync mode is unusably slow on some CPUs, so we disable it (drop to async) on > a per-cpu basis. The only difference is that we provide the switch to > userspace, since there isn't a functional problem. However, when we > inevitably hit real errata, we could even force the mode in the kernel > rather than disable the feature entirely. I think everyone assumes that sync is slow, so they'd only set it for debugging or some increased security. It's quite hard to quantify what a "too slow" sync is. > > The slight downside of the "upgrade" mode assumes that the user is aware > > that async is the fastest and asks for this unless it has specific > > needs. Of course, we can also extend the interface to "sync-force" or > > "sync-upgrade" etc. but I think it's over-engineered. > > Another reason I dislike "upgrade" is because it means that the kernel embeds > an ordering of which mode upgrades to another mode and, as new modes get > added by the architecture in future, this feels more like policy to me and > would be better off handled in userspace. Yeah, I don't like this aspect of the "upgrade" either but I'd accept it as a compromise. 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel