Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp10419576pxu; Wed, 30 Dec 2020 02:03:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJxCB0r6zLNFUtTv857Xj4mvWdhdjpqQtzqsJEY3vulGsgLG7jNlpiBNXQ71q/l2SBXL4Olx X-Received: by 2002:a17:906:810:: with SMTP id e16mr43966715ejd.34.1609322606419; Wed, 30 Dec 2020 02:03:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609322606; cv=none; d=google.com; s=arc-20160816; b=tS1fZ8lZHlaG5MHSG3Coca5nSh3AFPf1lOS9kFMjhd4NFChR1jTGH6M49doUDrV8Rl K8ZFCXhXrJ06PqVYz7Gv3fMUm8fKMGTbGWCX6XqMkBfPUD1sBTShMdBnQkKQHAi51PHP 2U4dX5+ghXDxdizJMoeaC3TqoOWQAp2pdsaPbcSMNnw4sVJcJKEA7veluU87iirZLmP8 MvAzHc0HXPtn6wRvTz8XaRg8V/D563SLuJcpqv+dEsti+/yFzxcurWnAU5epi4HYI/7i i0jQVM947WcLzItqlueFotxy8914NHgjf0NQg3TuASDu4D54h8DUBHYx+rj2G+lOkNHB 6Xcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=RLGcTHha1iBi5RnrUOHhCpmRRdZbNNy9N9/LhkhCawU=; b=n6mEoycsPC2Ga98AlO3uZPKtDGKgjvzPvv4QmR1kcLQSyMnUP4J5SpqlGyeOeaZcnZ pOdD3GnBrXZzbGIGVibZLuco2oAaQtdktUhLI7RlOwwQOqy5BYXOsCnMf8srxSePlCjy sMo8Tjt24Nbr97zrNhdk0H2j9Q/oYyX5+33fTDUp3IuUatucTAqcrej9nsKEwvpP5XI+ bJa43B5Td6IVWaa2xOAINPnE/xoJt1FPmwBQ0yXebF0kHS3nHxrIMMYjJAxnwdUTvHZO UtaIO9PvMszMRIoRKHWEubYSU7gDOM5DTX4Yg/7QFxwUWiwuutjbCbChnmgdl4ua8a4V k9fQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=p2p0MbfK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a10si21605216ejv.36.2020.12.30.02.03.03; Wed, 30 Dec 2020 02:03:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=p2p0MbfK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726240AbgL3KBf (ORCPT + 99 others); Wed, 30 Dec 2020 05:01:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725814AbgL3KBf (ORCPT ); Wed, 30 Dec 2020 05:01:35 -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 E9DEBC061799; Wed, 30 Dec 2020 02:00:39 -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-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RLGcTHha1iBi5RnrUOHhCpmRRdZbNNy9N9/LhkhCawU=; b=p2p0MbfKm1c8qLl/oYqAdf1c5 NSwPA81w4cjPSXGUfrJlixIAMI1qiuQ7JBKa9c5vBh4YgHdF0Jl+25BUYsCjR0frTf+ZCFe2U4LXA dPkGzPHZHMTMAbMr0rdcSUFc44dMCYe763lJr/QUsH4+0HztLsn3Mjq68nAJQMyuTict5YCIztQzI n6s+eLub2njYRmf+cXWAP4agnwvAjzJYz0xYFSrMDd/o9ZbURf5A95R8hC7HTrd+iP5UnwJDv+b98 3djV2uepw2kuTFjy5+kUg2ogjoiIwI7jdLtlQ7Vt2c5/VPzEVR1Z68PxpY1/p4sFkU2xtuRUu/Sz5 1tzF0cYVg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44902) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuYHP-0005bt-HE; Wed, 30 Dec 2020 10:00:31 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1kuYHM-00026D-M2; Wed, 30 Dec 2020 10:00:28 +0000 Date: Wed, 30 Dec 2020 10:00:28 +0000 From: Russell King - ARM Linux admin To: Nicholas Piggin Cc: paulmck , Arnd Bergmann , Jann Horn , Peter Zijlstra , Benjamin Herrenschmidt , x86 , linux-kernel , stable , Will Deacon , Mathieu Desnoyers , Michael Ellerman , Andy Lutomirski , Catalin Marinas , Paul Mackerras , linuxppc-dev , linux-arm-kernel Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() Message-ID: <20201230100028.GP1551@shell.armlinux.org.uk> References: <20201228190852.GI1551@shell.armlinux.org.uk> <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> <1609200902.me5niwm2t6.astroid@bobo.none> <1609210162.4d8dqilke6.astroid@bobo.none> <20201229104456.GK1551@shell.armlinux.org.uk> <1609290821.wrfh89v23a.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1609290821.wrfh89v23a.astroid@bobo.none> 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 Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote: > Excerpts from Russell King - ARM Linux admin's message of December 29, 2020 8:44 pm: > > On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote: > >> I think it should certainly be documented in terms of what guarantees > >> it provides to application, _not_ the kinds of instructions it may or > >> may not induce the core to execute. And if existing API can't be > >> re-documented sanely, then deprecatd and new ones added that DTRT. > >> Possibly under a new system call, if arch's like ARM want a range > >> flush and we don't want to expand the multiplexing behaviour of > >> membarrier even more (sigh). > > > > The 32-bit ARM sys_cacheflush() is there only to support self-modifying > > code, and takes whatever actions are necessary to support that. > > Exactly what actions it takes are cache implementation specific, and > > should be of no concern to the caller, but the underlying thing is... > > it's to support self-modifying code. > > Caveat > cacheflush() should not be used in programs intended to be portable. > On Linux, this call first appeared on the MIPS architecture, but nowa‐ > days, Linux provides a cacheflush() system call on some other architec‐ > tures, but with different arguments. > > What a disaster. Another badly designed interface, although it didn't > originate in Linux it sounds like we weren't to be outdone so > we messed it up even worse. > > flushing caches is neither necessary nor sufficient for code modification > on many processors. Maybe some old MIPS specific private thing was fine, > but certainly before it grew to other architectures, somebody should > have thought for more than 2 minutes about it. Sigh. WARNING: You are bordering on being objectionable and offensive with that comment. The ARM interface was designed by me back in the very early days of Linux, probably while you were still in dypers, based on what was known at the time. Back in the early 2000s, ideas such as relaxed memory ordering were not known. All there was was one level of harvard cache. So, juts shut up with your insults. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!