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.1 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 9E0E0C433E6 for ; Wed, 30 Dec 2020 10:01:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 61A4221D1B for ; Wed, 30 Dec 2020 10:01:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726289AbgL3KBf (ORCPT ); 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!