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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 A8435C2BA83 for ; Wed, 12 Feb 2020 17:03:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6AC8020658 for ; Wed, 12 Feb 2020 17:03:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6AC8020658 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F278E6B046C; Wed, 12 Feb 2020 12:03:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ED8DB6B046D; Wed, 12 Feb 2020 12:03:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E16676B046E; Wed, 12 Feb 2020 12:03:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id CB43B6B046C for ; Wed, 12 Feb 2020 12:03:56 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6CC711191E for ; Wed, 12 Feb 2020 17:03:56 +0000 (UTC) X-FDA: 76482097272.27.snail64_5256d246a73d X-HE-Tag: snail64_5256d246a73d X-Filterd-Recvd-Size: 2920 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Feb 2020 17:03:55 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2CF6630E; Wed, 12 Feb 2020 09:03:54 -0800 (PST) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 80FD73F68F; Wed, 12 Feb 2020 09:03:52 -0800 (PST) Date: Wed, 12 Feb 2020 17:03:50 +0000 From: Catalin Marinas To: Peter Collingbourne Cc: Evgenii Stepanov , Kostya Serebryany , Linux ARM , linux-arch@vger.kernel.org, Richard Earnshaw , Szabolcs Nagy , Marc Zyngier , Kevin Brodsky , linux-mm@kvack.org, Andrey Konovalov , Vincenzo Frascino , Will Deacon Subject: Re: [PATCH] arm64: mte: Clear SCTLR_EL1.TCF0 on exec Message-ID: <20200212170350.GB587247@arrakis.emea.arm.com> References: <20191220014853.223389-1-pcc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20191220014853.223389-1-pcc@google.com> Content-Transfer-Encoding: quoted-printable 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 Thu, Dec 19, 2019 at 05:48:53PM -0800, Peter Collingbourne wrote: > On Thu, Dec 19, 2019 at 12:32 PM Peter Collingbourne w= rote: > > On Wed, Dec 11, 2019 at 10:45 AM Catalin Marinas > > wrote: > > > + =A0 =A0 =A0 if (current->thread.sctlr_tcf0 !=3D next->thread.sctl= r_tcf0) > > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 update_sctlr_el1_tcf0(next->thread.sc= tlr_tcf0); > > > > I don't entirely understand why yet, but I've found that this check i= s > > insufficient for ensuring consistency between SCTLR_EL1.TCF0 and > > sctlr_tcf0. In my Android test environment with some processes having > > sctlr_tcf0=3DSCTLR_EL1_TCF0_SYNC and others having sctlr_tcf0=3D0, I = am > > seeing intermittent tag failures coming from the sctlr_tcf0=3D0 > > processes. With this patch: [...] > > Since sysreg_clear_set only sets the sysreg if it ended up changing, = I > > wouldn't expect this to cause a significant performance hit unless > > just reading SCTLR_EL1 is expensive. That being said, if the > > inconsistency is indicative of a deeper problem, we should probably > > address that. >=20 > I tracked it down to the flush_mte_state() function setting sctlr_tcf0 = but > failing to update SCTLR_EL1.TCF0. With this patch I am not seeing any m= ore > inconsistencies. Thanks Peter. I folded in your fix. --=20 Catalin