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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 47949C433DF for ; Wed, 27 May 2020 09:55:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E28DB20EDD for ; Wed, 27 May 2020 09:55:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0E4osRJD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E28DB20EDD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 49F43800BE; Wed, 27 May 2020 05:55:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 44FB280010; Wed, 27 May 2020 05:55:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36408800BE; Wed, 27 May 2020 05:55:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id 1D65280010 for ; Wed, 27 May 2020 05:55:13 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CA49410FB0 for ; Wed, 27 May 2020 09:55:12 +0000 (UTC) X-FDA: 76862040864.02.step78_4c03b2226d51 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id B123010FAC for ; Wed, 27 May 2020 09:55:12 +0000 (UTC) X-HE-Tag: step78_4c03b2226d51 X-Filterd-Recvd-Size: 6114 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 May 2020 09:55:11 +0000 (UTC) Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0ECDD20B80; Wed, 27 May 2020 09:55:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590573311; bh=fus0z074K2+v5viezNh5aSTINzkfZlDW5gDLPTcN3rs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0E4osRJDeF5F9676q35dVh44ubGc76fAsV838gxtkC0dMpGT+R8yCAz744kJTI6vv +omcCl+atGm3jy4pKReRU4Gg0HdBFfoVtavYZR/imqGupWJKP+XANkpWp3pTqLJqtM N5eQfGrHl4rf9HtHLPDBh8apf64eXXFp2aLbdclc= Date: Wed, 27 May 2020 10:55:05 +0100 From: Will Deacon To: Patrick Daly Cc: Catalin Marinas , linux-arch@vger.kernel.org, Vladimir Murzin , Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , Peter Collingbourne , linux-mm@kvack.org, Vincenzo Frascino , Dave P Martin , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 24/26] arm64: mte: Introduce early param to disable MTE support Message-ID: <20200527095504.GB11111@willie-the-truck> References: <20200515171612.1020-1-catalin.marinas@arm.com> <20200515171612.1020-25-catalin.marinas@arm.com> <20200518113103.GA32394@willie-the-truck> <20200518172054.GL9862@gaia> <20200522055710.GA25791@pdaly-linux.qualcomm.com> <20200522103714.GA26492@gaia> <20200527021153.GA24439@pdaly-linux.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200527021153.GA24439@pdaly-linux.qualcomm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: B123010FAC X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, May 26, 2020 at 07:11:53PM -0700, Patrick Daly wrote: > On Fri, May 22, 2020 at 11:37:15AM +0100, Catalin Marinas wrote: > > On Thu, May 21, 2020 at 10:57:10PM -0700, Patrick Daly wrote: > > > On Mon, May 18, 2020 at 06:20:55PM +0100, Catalin Marinas wrote: > > > > On Mon, May 18, 2020 at 12:31:03PM +0100, Will Deacon wrote: > > > > > On Mon, May 18, 2020 at 12:26:30PM +0100, Vladimir Murzin wrote: > > > > > > On 5/15/20 6:16 PM, Catalin Marinas wrote: > > > > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > > > > > > > index f2a93c8679e8..7436e7462b85 100644 > > > > > > > --- a/Documentation/admin-guide/kernel-parameters.txt > > > > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > > > > > > @@ -373,6 +373,10 @@ > > > > > > > arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards > > > > > > > Format: ,, > > > > > > > > > > > > > > + arm64.mte_disable= > > > > > > > + [ARM64] Disable Linux support for the Memory > > > > > > > + Tagging Extension (both user and in-kernel). > > > > > > > + > > > > > > > > > > > > Should it really to take parameter (on/off/true/false)? It may lead to expectation > > > > > > that arm64.mte_disable=false should enable MT and, yes, double negatives make it > > > > > > look ugly, so if we do need parameter, can it be arm64.mte=on/off/true/false? > > > > > > > > > > I don't think "performance analysis" is a good justification for this > > > > > parameter tbh. We don't tend to add these options for other architectural > > > > > features, and I don't see why MTE is any different in this regard. > > > > > > > > There is an expectation of performance impact with MTE enabled, > > > > especially if it's running in synchronous mode. For the in-kernel MTE, > > > > we could add a parameter which sets sync vs async at boot time rather > > > > than a big disable knob. It won't affect user space however. > > > > > > > > The other 'justification' is if your hardware has weird unexpected > > > > behaviour but I'd like this handled via errata workarounds. > > > > > > > > I'll let the people who asked for this to chip in ;). I agree with you > > > > that we rarely add these (and I rejected a similar option a few weeks > > > > ago on the AMU patchset). > > > > > > We've been looking into other ways this on/off behavior could be achieved. > > > > The actual question here is what the on/off behaviour is needed for. We > > can figure out the best mechanism for this once we know what we want to > > achieve. My wild guess above was performance analysis but that can be > > toggled by either kernel boot parameter or run-time sysctl (or just the > > Kconfig option). > > > > If it is about forcing user space not to use MTE, we may look into some > > other sysctl controls (we already have one for the tagged address ABI). > > We want to allow the end user to be able to easily "opt out" of MTE in favour > of better power, perf and battery life. Who is "the end user" in this case? If MTE is bad enough for power, performance and battery life that we need a kill switch, then perhaps we shouldn't enable it by default and the few people that want to use it can build a kernel with it enabled. However, then I don't really see what MTE buys you over the existing KASAN implementations. I thought the general idea was that you could run in the (cheap) "async" mode, and then re-run in the more expensive "sync" mode to further diagnose any failures. That model seems to work well with these patches, since reporting is disabled by default. Are you saying that there is a significant penalty incurred even when reporting is not enabled? Anyway, we don't offer global runtime/cmdline switches for the vast majority of other architectural features -- instead, we choose a sensible default, and I think we should do the same here. Will