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,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 2C2C3C2B9F4 for ; Fri, 25 Jun 2021 13:55:19 +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 EA4D161956 for ; Fri, 25 Jun 2021 13:55:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA4D161956 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=HMwkdHcesAkiCSuK4ID/YB5bU1wMOOlanC6aSrleEWE=; b=xPbOU1paGbN7XR BPLjQ+ZW4rOuTAyYVLD68GhpDa2+E21Mt+G1jiaWR+NKT5ixgoG8l5Wyu44FIR86IqjRQLAJGj/US X0dNj+HkNZGqP3bZ44YxZk6R2Bzz3ePkt7OFh7cKGTIUJc+OhSftlXAFxK4fDOi6+q4eYx5k/prZ8 Lh9qgqcPU2whARTE73+2HQ7NP0Nzd+1gFHtOe80e+KqqaL7ds0jT7EDWc4uOm0BltrHz7QaWoJt8/ BR0qs3Baa5nXfZ7wBt4s52pB544s6s9eWkkbXBjCDSfwljNznb1H90/l5wORGZ+GMrNIMZfpt0Io9 xaYSxU1vXy46G03pVSIA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwmHO-001nPO-E9; Fri, 25 Jun 2021 13:53:58 +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 1lwmHK-001nOm-M1 for linux-arm-kernel@lists.infradead.org; Fri, 25 Jun 2021 13:53:56 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 293CF60241; Fri, 25 Jun 2021 13:53:53 +0000 (UTC) Date: Fri, 25 Jun 2021 14:53:50 +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: <20210625135350.GD20835@arm.com> References: <20210621123936.GB29283@willie-the-truck> <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210625123959.GB3170@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-20210625_065354_782027_F62EFB6D X-CRM114-Status: GOOD ( 31.27 ) 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 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. > 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. 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. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel