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=-3.8 required=3.0 tests=BAYES_00, 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 432EFC2B9F4 for ; Thu, 17 Jun 2021 14:21:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6459613A9 for ; Thu, 17 Jun 2021 14:21:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6459613A9 Authentication-Results: mail.kernel.org; dmarc=fail (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 4075D6B006E; Thu, 17 Jun 2021 10:21:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B7C56B0071; Thu, 17 Jun 2021 10:21:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 231AE6B0072; Thu, 17 Jun 2021 10:21:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id E4BC46B006E for ; Thu, 17 Jun 2021 10:21:20 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8A6AD181AEF07 for ; Thu, 17 Jun 2021 14:21:20 +0000 (UTC) X-FDA: 78263428320.12.E386B1D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 63E8AC00CBFC for ; Thu, 17 Jun 2021 14:21:09 +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 1DF6E12FC; Thu, 17 Jun 2021 07:21:19 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 83CBC3F719; Thu, 17 Jun 2021 07:21:16 -0700 (PDT) Date: Thu, 17 Jun 2021 15:20:46 +0100 From: Mark Rutland To: Andy Lutomirski Cc: "Russell King (Oracle)" , the arch/x86 maintainers , Dave Hansen , Linux Kernel Mailing List , linux-mm@kvack.org, Andrew Morton , Mathieu Desnoyers , Nicholas Piggin , "Peter Zijlstra (Intel)" , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 7/8] membarrier: Remove arm (32) support for SYNC_CORE Message-ID: <20210617142046.GA87858@C02TD0UTHF1T.local> References: <2142129092ff9aa00e600c42a26c4015b7f5ceec.1623813516.git.luto@kernel.org> <20210617103524.GA82133@C02TD0UTHF1T.local> <20210617112305.GK22278@shell.armlinux.org.uk> <20210617113349.GB82133@C02TD0UTHF1T.local> <394219d4-36a6-4e7f-a03c-8590551b099a@www.fastmail.com> <20210617135133.GA86101@C02TD0UTHF1T.local> <33241b25-4d45-4278-a4e6-ec9c12b0e1f3@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <33241b25-4d45-4278-a4e6-ec9c12b0e1f3@www.fastmail.com> Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com; dmarc=pass (policy=none) header.from=arm.com X-Stat-Signature: xsy6abgdxte68uhf9yjhkrnzy6umqdf5 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 63E8AC00CBFC X-HE-Tag: 1623939669-824097 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, Jun 17, 2021 at 07:00:26AM -0700, Andy Lutomirski wrote: >=20 >=20 > On Thu, Jun 17, 2021, at 6:51 AM, Mark Rutland wrote: > > On Thu, Jun 17, 2021 at 06:41:41AM -0700, Andy Lutomirski wrote: >=20 > > > In any event, I=E2=80=99m even more convinced that no new SYNC_CORE= arches > > > should be added. We need a new API that just does the right thing.=20 > >=20 > > My intuition is the other way around, and that this is a gnereally > > useful thing for architectures that require context synchronization. >=20 > Except that you can't use it in a generic way. You have to know the > specific rules for your arch. That's generally true for modifying instruction streams though? The man page for cacheflush(2) calls out that it is not portable. I think what's necessary here is some mandatory per-arch documentation? > > It's not clear to me what "the right thing" would mean specifically, = and > > on architectures with userspace cache maintenance JITs can usually do > > the most optimal maintenance, and only need help for the context > > synchronization. > >=20 >=20 > This I simply don't believe -- I doubt that any sane architecture > really works like this. I wrote an email about it to Intel that > apparently generated internal discussion but no results. Consider: >=20 > mmap(some shared library, some previously unmapped address); >=20 > this does no heavyweight synchronization, at least on x86. There is > no "serializing" instruction in the fast path, and it *works* despite > anything the SDM may or may not say. Sure, and I called this case out specifically when I said: | * Where we can guarantee that a CPU cannot possibly have an | instruction in-flight (e.g. due to a lack of a mapping to fetch | instructions from), nothing is necessary. This is what we rely on | when faulting in code pages. In these cases, the CPU is liable to | take fault on the missing translation anyway. .. what really matters is whether the CPU had the oppoprtunity to fetch something stale; the context synchronization is necessary to discard that. Bear in mind that in many cases where this could occur in theory, we don't hit in practice because CPUs don't happen to predict/speculate as aggressively as they are permitted to. On arm/arm64 it's obvious that this is a problem because the documentation clearly defines the boundaries of what a CPU is permitted to do, whereas on other architectures docuentation is not necessarily as clear whether this is permited or whether the architecture mandates additional guarantees. > We can and, IMO, should develop a sane way for user programs to > install instructions into VMAs, for security-conscious software to > verify them (by splitting the read and write sides?), and for their > consumers to execute them, without knowing any arch details. And I > think this can be done with no IPIs except for possible TLB flushing > when needed, at least on most architectures. It would require a > nontrivial amount of design work, and it would not resemble > sys_cacheflush() or SYNC_CORE. I'm not opposed to adding new interfaces for stuff like that, but I don't think that membarrier(SYNC_CORE) or cacheflush(2) are necessarily wrong as-is. Thanks, Mark.