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.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 169DFC433E6 for ; Mon, 28 Dec 2020 10:26:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3A282242A for ; Mon, 28 Dec 2020 10:26:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727189AbgL1K0k (ORCPT ); Mon, 28 Dec 2020 05:26:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727080AbgL1K0j (ORCPT ); Mon, 28 Dec 2020 05:26:39 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA2F8C061795; Mon, 28 Dec 2020 02:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KFHMNIJdJQgc7k2MpIWgEZIVRXKh/hl0VpPbl95Wj24=; b=h30/GxdgAhHlsBbJPSjlJ8Mug 9M1YG6RYYa/gwy5tEt6qDesqLU2ezI2zY0VuJgJZS2sgz8cuBtJbDnH4HxigRXUUhDIx1hPBRuiTk lZxIdGgnk9leKNqn0Ez2tBKl8ZyUMTp+wcNjizIlk1FW1Cw9yOzCn5Q6cYRndJo51zAP6allXlrrU Oo7bDiUkZwnIBHqdr+VCfUn3qCmOUzN5Cd0UMG1P0wzdNyotxaag/94/kmDJOpznJlcfiWaoaRut0 F76z3eNzY2KD85mOAGw14rTXAMSQ72umaaa6LpJrHqH3Ofaz3fy397PGK0IkueabDrOeV+UZ/fuXm V76NAbWCw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44598) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ktpig-0004Lr-Ob; Mon, 28 Dec 2020 10:25:42 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1ktpib-0000CL-9P; Mon, 28 Dec 2020 10:25:37 +0000 Date: Mon, 28 Dec 2020 10:25:37 +0000 From: Russell King - ARM Linux admin To: Andy Lutomirski Cc: Mathieu Desnoyers , x86 , linux-kernel , Nicholas Piggin , Arnd Bergmann , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , Catalin Marinas , Will Deacon , linux-arm-kernel , stable Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() Message-ID: <20201228102537.GG1551@shell.armlinux.org.uk> References: <1836294649.3345.1609100294833.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Russell King - ARM Linux admin Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote: > On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers > wrote: > > > > ----- On Dec 27, 2020, at 1:28 PM, Andy Lutomirski luto@kernel.org wrote: > > > > > > > > > I admit that I'm rather surprised that the code worked at all on arm64, > > > and I'm suspicious that it has never been very well tested. My apologies > > > for not reviewing this more carefully in the first place. > > > > Please refer to Documentation/features/sched/membarrier-sync-core/arch-support.txt > > > > It clearly states that only arm, arm64, powerpc and x86 support the membarrier > > sync core feature as of now: > > Sigh, I missed arm (32). Russell or ARM folks, what's the right > incantation to make the CPU notice instruction changes initiated by > other cores on 32-bit ARM? You need to call flush_icache_range(), since the changes need to be flushed from the data cache to the point of unification (of the Harvard I and D), and the instruction cache needs to be invalidated so it can then see those updated instructions. This will also take care of the necessary barriers that the CPU requires for you. ... as documented in Documentation/core-api/cachetlb.rst and so should be available on every kernel supported CPU. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!