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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 ABC0CC2B9F4 for ; Mon, 28 Jun 2021 10:16:15 +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 7D02D61C6A for ; Mon, 28 Jun 2021 10:16:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D02D61C6A 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=6xrdGEeSnsbI+X1TgvaYlB2q47mACnPXK7SdIeskb7o=; b=lXwzFx3WVEtL+d G4E1zXTpdAtwHfNJVNYOfuYS8luMPHTIuwYBKKahhWVmAZ2R6nJsVquNFbcdrYfLiHCXp4YIe15dd VEf40CWb4VDCGFpQes4jAzi6nehE+hjJXMB7N7/J/erLrjoFor4LOqCotBf818K3orddQKnXdiJs3 TMq4LTK7esWV6cxMmda8bXsb5z/k9C7AnUq2pnEb+eBxAi+7j+FVwJR4MzNawMfJiZV9R4MSnSw+p H7fifyv5ArYQC5hOFhgg/FtV66PA/SCa2mD9w1LT43tiadp+c4e4fkJMmRm357mJFmXTs3QKHOKzO ZQevT2LPS3HEfvvJN/YA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lxoI5-007axp-RN; Mon, 28 Jun 2021 10:14:57 +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 1lxoI2-007axN-Dr for linux-arm-kernel@lists.infradead.org; Mon, 28 Jun 2021 10:14:55 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6988661C6A; Mon, 28 Jun 2021 10:14:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624875293; bh=HLgQCAzsv+TYyxyeq01EBcDPh0jkGaKPC39JTZgJFEQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mYLLJCoaVFhohnf7DZe8uPHIQoep4S7phqSfrxWcXod757fSVEforQ/9pZZMGpiVB 3Oo4XMyN361Q2wGshhx93wDrjJByKEagfW0PNhTKf7q1l+EWhUimRqFaTWraWUNB+R b6cwI8nK38OxM5tvTlrh4oc0oXSGreZiKtNV4pzbfnF8JIOmkY3hCNKWLWsAC2A8Wx qr5d0DP4zB/hgNzhChWnNBchMKtAK1hFkr9OI8IJcYTKhVcoLLx6fGIsx2+iDBThvu YTx/OOYX6kKmQOUWh3Gn0lh+JPBndSJALIg8RLxlLu7HMRJXmqrFTlk4RZAhTwTx9z Vdh/ca1afw/5A== Date: Mon, 28 Jun 2021 11:14:49 +0100 From: Will Deacon To: Catalin Marinas 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: <20210628101448.GA5503@willie-the-truck> References: <20210621151858.GC11552@arm.com> <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210625135350.GD20835@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-20210628_031454_543374_67DB7C4A X-CRM114-Status: GOOD ( 42.14 ) 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 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. > > 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. > 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. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel