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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0A928C433F5 for ; Tue, 8 Mar 2022 18:27:56 +0000 (UTC) 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=eefX98I5awLFm7rlg+58FWVdCuWednHycN5uuY5Byqs=; b=F+/MygPh8/QGmL AAXMwAHhDe04rCkgUGIO9Y5FvFm9usai6PpV5/mRHmmf7vcAulYFGi70GI+rEC8AGiyj1sUsNiWqP 6R8I8cTO6J5qucZwfy2qmdOwOISc3owTNDy7iH+uLjKP//+YkLYIAZSdog1cH2WW/nhpZwz7atKHJ GrYVSt02bw9rjrB0N4kZJbdk5hSSMPI1nDyLE+PR6u1Q+hQiyISrtBr1ge344wwi9Fa/X/8cmyinb yTP1DJe2UC1mlunCsBX8tcMOGUZlmAiEY+aHnxgou7VyXg+K44yz/gFAja5F1Dh2S2W8yoTjFayYP 2Ezl+ivsdzpLTpEe2Fkw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nReXl-005mXg-U8; Tue, 08 Mar 2022 18:26:46 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nReXh-005mX7-S2 for linux-arm-kernel@lists.infradead.org; Tue, 08 Mar 2022 18:26:43 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2B178615F5; Tue, 8 Mar 2022 18:26:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04646C340EB; Tue, 8 Mar 2022 18:26:38 +0000 (UTC) Date: Tue, 8 Mar 2022 18:26:35 +0000 From: Catalin Marinas To: Peter Collingbourne Cc: Szabolcs Nagy , Evgenii Stepanov , Mark Brown , Will Deacon , Joey Gouly , Branislav Rankov , Linux ARM Subject: Re: [PATCH v1 4/4] arm64/mte: Add userspace interface for enabling asymmetric mode Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220308_102642_008646_EDBF180D X-CRM114-Status: GOOD ( 27.65 ) 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, Mar 07, 2022 at 12:55:28PM -0800, Peter Collingbourne wrote: > On Mon, Mar 7, 2022 at 7:36 AM Catalin Marinas wrote: > > Only allowing asymmetric mode if both symmetric and async are supported > > is not that confusing. The only downside is that one cannot ask for > > asymmetric mode only but is this such a big problem? For testing one can > > always set the sysfs preferred mode to asymm. It will be some time > > before we see asymm in production. > > It could be a problem on Android because one of the modes that we > intend to expose to application developers is "asymm-only" (as opposed > to "upgradable asymm"). This would be used by developers who need a > finer grained control over the MTE mode used in their application. > Although to be honest I'm not 100% certain that we would need this > mode so perhaps we could live with just the "upgradable asymm" mode. With the introduction of the preferred mode, we kind of agreed that an application doesn't necessarily know what it wants and we should leave this decision to the kernel (via sysfs) as it knows the performance aspects better. To avoid confusing applications, we changed the TCF field in prctl() from an exact mode to a supported mode mask so that an app is not take by surprise. Now, the asymmetric mode is just a combination of sync and async, and an app just states that it supports both. It's not any different from the kernel changing the preferred mode at run-time. We can later add a new bit, "force asymm" or something if needed while still requiring that both async and sync bits are set. So I'm tempted to go with Mark's latest patch, once I looked at it. > > Assuming we have a different prctl() for setting TCF, what would we > > report in the current PR_GET_ for existing apps when only the asymm mode > > was set? By the same logic as the TCF mask breaking current apps, this > > doesn't work if somehow an app uses the information and, for example, > > retry a faulting operation indefinitely. > > One option may be to reject the GET with EINVAL if ASYMM is set. This > should hopefully result in the application acting as if MTE is not > enabled/supported. Well, the app still gets TCF faults while it may have concluded that MTE is disabled. We can't always guess what the user wants (and the history around this ABI shows this). Anyway, I'm open to improving the ABI later but I don't think we should delay the asym MTE patches, especially if we merge Mark's asym removal from prctl(). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel