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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 88BD5C433E9 for ; Mon, 28 Dec 2020 23:03:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 682DB2222A for ; Mon, 28 Dec 2020 23:03:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731475AbgL1W4J (ORCPT ); Mon, 28 Dec 2020 17:56:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:49452 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729486AbgL1VHu (ORCPT ); Mon, 28 Dec 2020 16:07:50 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 30F5A225AB for ; Mon, 28 Dec 2020 21:07:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609189629; bh=27KIURwqt1RL2uI90GMMltkVqkqP6J5+DLiEDUmWBQU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DtQTxCxMN4G6UUHNKgX6MwbZUqPdjE6JjBxXZPdj0zWdX7gsZSDdo/C8xwp+lQL54 NBzKb3iMOLLl+ooPPX+uDCXfGSGiAJGCyGuQPPxE89gl/uIHrwh/HV+RGF5/LVTpQ4 7xR85q4ojktFqvTOuAoTFu5ysSy5NRBPttYeK643j5DLOtPQanqRbL339jIUFnX7Uj 1TsfvHMwMFcF8emTrLa4I9yh+VeQmGSVkWzMHIJyvLWndSC3wqlRmenlposPQkFlCJ HR+88klPTEYBgGF6Bk68JJRI3iceniZzpHlfVMC5fiuZLPwxWw3g3WHtjhCwtsI+b5 TdxMw2v6zY+xg== Received: by mail-wr1-f54.google.com with SMTP id t16so12538252wra.3 for ; Mon, 28 Dec 2020 13:07:09 -0800 (PST) X-Gm-Message-State: AOAM531M66HSOGt5rBPY84iMEMCylvKnwxbuJ73ZZ2WExCe43VVokpp0 Q1bjuhWsmhOgqu35kJ1gIZ5rr/tH+xqn8tWfGOJAjA== X-Google-Smtp-Source: ABdhPJzLxjROX7Kr2gE7TOhHSUuU+1LZHqFzLu9v1+05RcKic1KF5QVniGH4/+FdCVG2zacKFF1YcGM3iKhXVViXwfc= X-Received: by 2002:a5d:62c7:: with SMTP id o7mr846007wrv.257.1609189627549; Mon, 28 Dec 2020 13:07:07 -0800 (PST) MIME-Version: 1.0 References: <1836294649.3345.1609100294833.JavaMail.zimbra@efficios.com> <20201228102537.GG1551@shell.armlinux.org.uk> <20201228190852.GI1551@shell.armlinux.org.uk> <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> In-Reply-To: <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> From: Andy Lutomirski Date: Mon, 28 Dec 2020 13:06:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Mathieu Desnoyers Cc: Andy Lutomirski , paulmck , Peter Zijlstra , "Russell King, ARM Linux" , Jann Horn , Will Deacon , x86 , linux-kernel , Nicholas Piggin , Arnd Bergmann , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , Catalin Marinas , linux-arm-kernel , stable Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers wrote: > > ----- On Dec 28, 2020, at 2:44 PM, Andy Lutomirski luto@kernel.org wrote: > > > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin > > wrote: > >> > >> On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote: > >> > After chatting with rmk about this (but without claiming that any of > >> > this is his opinion), based on the manpage, I think membarrier() > >> > currently doesn't really claim to be synchronizing caches? It just > >> > serializes cores. So arguably if userspace wants to use membarrier() > >> > to synchronize code changes, userspace should first do the code > >> > change, then flush icache as appropriate for the architecture, and > >> > then do the membarrier() to ensure that the old code is unused? > > ^ exactly, yes. > > >> > > >> > For 32-bit arm, rmk pointed out that that would be the cacheflush() > >> > syscall. That might cause you to end up with two IPIs instead of one > >> > in total, but we probably don't care _that_ much about extra IPIs on > >> > 32-bit arm? > > This was the original thinking, yes. The cacheflush IPI will flush specific > regions of code, and the membarrier IPI issues context synchronizing > instructions. > > Architectures with coherent i/d caches don't need the cacheflush step. There are different levels of coherency -- VIVT architectures may have differing requirements compared to PIPT, etc. In any case, I feel like the approach taken by the documentation is fundamentally confusing. Architectures don't all speak the same language How about something like: The SYNC_CORE operation causes all threads in the caller's address space (including the caller) to execute an architecture-defined barrier operation. membarrier() will ensure that this barrier is executed at a time such that all data writes done by the calling thread before membarrier() are made visible by the barrier. Additional architecture-dependent cache management operations may be required to use this for JIT code. x86: SYNC_CORE executes a barrier that will cause subsequent instruction fetches to observe prior writes. Currently this will be a "serializing" instruction, but, if future improved CPU documentation becomes available and relaxes this requirement, the barrier may change. The kernel guarantees that writing new or modified instructions to normal memory (and issuing SFENCE if the writes were non-temporal) then doing a membarrier SYNC_CORE operation is sufficient to cause all threads in the caller's address space to execute the new or modified instructions. This is true regardless of whether or not those instructions are written at the same virtual address from which they are subsequently executed. No additional cache management is required on x86. arm: Something about the cache management syscalls. arm64: Ditto powerpc: I have no idea. 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,DKIM_INVALID, DKIM_SIGNED,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 02FB2C433DB for ; Mon, 28 Dec 2020 21:08:52 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0BFFE207C9 for ; Mon, 28 Dec 2020 21:08:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BFFE207C9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4D4VXK0C7TzDqGG for ; Tue, 29 Dec 2020 08:08:49 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=luto@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=DtQTxCxM; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4D4VVS3GwTzDqCp for ; Tue, 29 Dec 2020 08:07:11 +1100 (AEDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id F23F1207C9 for ; Mon, 28 Dec 2020 21:07:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609189629; bh=27KIURwqt1RL2uI90GMMltkVqkqP6J5+DLiEDUmWBQU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DtQTxCxMN4G6UUHNKgX6MwbZUqPdjE6JjBxXZPdj0zWdX7gsZSDdo/C8xwp+lQL54 NBzKb3iMOLLl+ooPPX+uDCXfGSGiAJGCyGuQPPxE89gl/uIHrwh/HV+RGF5/LVTpQ4 7xR85q4ojktFqvTOuAoTFu5ysSy5NRBPttYeK643j5DLOtPQanqRbL339jIUFnX7Uj 1TsfvHMwMFcF8emTrLa4I9yh+VeQmGSVkWzMHIJyvLWndSC3wqlRmenlposPQkFlCJ HR+88klPTEYBgGF6Bk68JJRI3iceniZzpHlfVMC5fiuZLPwxWw3g3WHtjhCwtsI+b5 TdxMw2v6zY+xg== Received: by mail-wr1-f48.google.com with SMTP id r7so12517404wrc.5 for ; Mon, 28 Dec 2020 13:07:08 -0800 (PST) X-Gm-Message-State: AOAM532czUv2hPigLUamYSouFYKF99HVqAzcIewfcF4VTQ1fVeoFGQpB xiyhAaYPTYiVniJCQuUdkzhASHQCPIImYrflRgQUyA== X-Google-Smtp-Source: ABdhPJzLxjROX7Kr2gE7TOhHSUuU+1LZHqFzLu9v1+05RcKic1KF5QVniGH4/+FdCVG2zacKFF1YcGM3iKhXVViXwfc= X-Received: by 2002:a5d:62c7:: with SMTP id o7mr846007wrv.257.1609189627549; Mon, 28 Dec 2020 13:07:07 -0800 (PST) MIME-Version: 1.0 References: <1836294649.3345.1609100294833.JavaMail.zimbra@efficios.com> <20201228102537.GG1551@shell.armlinux.org.uk> <20201228190852.GI1551@shell.armlinux.org.uk> <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> In-Reply-To: <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> From: Andy Lutomirski Date: Mon, 28 Dec 2020 13:06:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Mathieu Desnoyers Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev , Catalin Marinas , Arnd Bergmann , paulmck , Jann Horn , Peter Zijlstra , x86 , "Russell King, ARM Linux" , Nicholas Piggin , linux-kernel , Paul Mackerras , stable , Andy Lutomirski , Will Deacon , linux-arm-kernel Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers wrote: > > ----- On Dec 28, 2020, at 2:44 PM, Andy Lutomirski luto@kernel.org wrote: > > > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin > > wrote: > >> > >> On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote: > >> > After chatting with rmk about this (but without claiming that any of > >> > this is his opinion), based on the manpage, I think membarrier() > >> > currently doesn't really claim to be synchronizing caches? It just > >> > serializes cores. So arguably if userspace wants to use membarrier() > >> > to synchronize code changes, userspace should first do the code > >> > change, then flush icache as appropriate for the architecture, and > >> > then do the membarrier() to ensure that the old code is unused? > > ^ exactly, yes. > > >> > > >> > For 32-bit arm, rmk pointed out that that would be the cacheflush() > >> > syscall. That might cause you to end up with two IPIs instead of one > >> > in total, but we probably don't care _that_ much about extra IPIs on > >> > 32-bit arm? > > This was the original thinking, yes. The cacheflush IPI will flush specific > regions of code, and the membarrier IPI issues context synchronizing > instructions. > > Architectures with coherent i/d caches don't need the cacheflush step. There are different levels of coherency -- VIVT architectures may have differing requirements compared to PIPT, etc. In any case, I feel like the approach taken by the documentation is fundamentally confusing. Architectures don't all speak the same language How about something like: The SYNC_CORE operation causes all threads in the caller's address space (including the caller) to execute an architecture-defined barrier operation. membarrier() will ensure that this barrier is executed at a time such that all data writes done by the calling thread before membarrier() are made visible by the barrier. Additional architecture-dependent cache management operations may be required to use this for JIT code. x86: SYNC_CORE executes a barrier that will cause subsequent instruction fetches to observe prior writes. Currently this will be a "serializing" instruction, but, if future improved CPU documentation becomes available and relaxes this requirement, the barrier may change. The kernel guarantees that writing new or modified instructions to normal memory (and issuing SFENCE if the writes were non-temporal) then doing a membarrier SYNC_CORE operation is sufficient to cause all threads in the caller's address space to execute the new or modified instructions. This is true regardless of whether or not those instructions are written at the same virtual address from which they are subsequently executed. No additional cache management is required on x86. arm: Something about the cache management syscalls. arm64: Ditto powerpc: I have no idea. 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=-4.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 2FB18C433DB for ; Mon, 28 Dec 2020 21:08:34 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D2BC5207C9 for ; Mon, 28 Dec 2020 21:08:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D2BC5207C9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z5hB1wp8Vfm6JorHwGB/Mr+KFtDlGuCkRq3a9WOXLso=; b=ia1AUc0xOH59WGS7M7HzG9KVl dQaqs4mCYJ+2euhgLR81/33eFRtpV7Hjf+YsWaY1B9ZsZfNmB1ZYNla5kA6VX3DVRHn92z+dXCset becrkFJCsY9FJKi3OICyvZCp7mF0euZZefJRX3I+/n5ckZqSPJ7i3YaZLqFrSG3R9GIhtb8diSB0Y Hu/79CgGfbzvPIuAgbPJ1R1BZCY5my++uBBTqcCi0cG2LJHFns1aqzssirmTSrKrVBJtPqbgJ6nTi YsfQFMPLY3nSUCS8x1DE+0fn839qUiO6ZlRtfAOgaZttgjvurxt00By5Im3g5UJVyhiXTaIRtnHGd 5qRM0D0aQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ktzjW-0003Lj-IB; Mon, 28 Dec 2020 21:07:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ktzjS-0003KR-QF for linux-arm-kernel@lists.infradead.org; Mon, 28 Dec 2020 21:07:12 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 16127223E8 for ; Mon, 28 Dec 2020 21:07:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609189629; bh=27KIURwqt1RL2uI90GMMltkVqkqP6J5+DLiEDUmWBQU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DtQTxCxMN4G6UUHNKgX6MwbZUqPdjE6JjBxXZPdj0zWdX7gsZSDdo/C8xwp+lQL54 NBzKb3iMOLLl+ooPPX+uDCXfGSGiAJGCyGuQPPxE89gl/uIHrwh/HV+RGF5/LVTpQ4 7xR85q4ojktFqvTOuAoTFu5ysSy5NRBPttYeK643j5DLOtPQanqRbL339jIUFnX7Uj 1TsfvHMwMFcF8emTrLa4I9yh+VeQmGSVkWzMHIJyvLWndSC3wqlRmenlposPQkFlCJ HR+88klPTEYBgGF6Bk68JJRI3iceniZzpHlfVMC5fiuZLPwxWw3g3WHtjhCwtsI+b5 TdxMw2v6zY+xg== Received: by mail-wr1-f51.google.com with SMTP id w5so12491552wrm.11 for ; Mon, 28 Dec 2020 13:07:09 -0800 (PST) X-Gm-Message-State: AOAM530EdFKdDyzkBSvI0YG28LI+Dn7mVX3RG4f7t4sixQaUc3D9Y8LB yyD+zSU8ePlb10c5OF2HARmmqUvQolc9iPH4fCBQww== X-Google-Smtp-Source: ABdhPJzLxjROX7Kr2gE7TOhHSUuU+1LZHqFzLu9v1+05RcKic1KF5QVniGH4/+FdCVG2zacKFF1YcGM3iKhXVViXwfc= X-Received: by 2002:a5d:62c7:: with SMTP id o7mr846007wrv.257.1609189627549; Mon, 28 Dec 2020 13:07:07 -0800 (PST) MIME-Version: 1.0 References: <1836294649.3345.1609100294833.JavaMail.zimbra@efficios.com> <20201228102537.GG1551@shell.armlinux.org.uk> <20201228190852.GI1551@shell.armlinux.org.uk> <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> In-Reply-To: <1086654515.3607.1609187556216.JavaMail.zimbra@efficios.com> From: Andy Lutomirski Date: Mon, 28 Dec 2020 13:06:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Mathieu Desnoyers X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201228_160711_060943_ACD4CEEE X-CRM114-Status: GOOD ( 24.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev , Catalin Marinas , Arnd Bergmann , paulmck , Jann Horn , Peter Zijlstra , Michael Ellerman , x86 , "Russell King, ARM Linux" , Nicholas Piggin , linux-kernel , Paul Mackerras , stable , Andy Lutomirski , Benjamin Herrenschmidt , Will Deacon , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers wrote: > > ----- On Dec 28, 2020, at 2:44 PM, Andy Lutomirski luto@kernel.org wrote: > > > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin > > wrote: > >> > >> On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote: > >> > After chatting with rmk about this (but without claiming that any of > >> > this is his opinion), based on the manpage, I think membarrier() > >> > currently doesn't really claim to be synchronizing caches? It just > >> > serializes cores. So arguably if userspace wants to use membarrier() > >> > to synchronize code changes, userspace should first do the code > >> > change, then flush icache as appropriate for the architecture, and > >> > then do the membarrier() to ensure that the old code is unused? > > ^ exactly, yes. > > >> > > >> > For 32-bit arm, rmk pointed out that that would be the cacheflush() > >> > syscall. That might cause you to end up with two IPIs instead of one > >> > in total, but we probably don't care _that_ much about extra IPIs on > >> > 32-bit arm? > > This was the original thinking, yes. The cacheflush IPI will flush specific > regions of code, and the membarrier IPI issues context synchronizing > instructions. > > Architectures with coherent i/d caches don't need the cacheflush step. There are different levels of coherency -- VIVT architectures may have differing requirements compared to PIPT, etc. In any case, I feel like the approach taken by the documentation is fundamentally confusing. Architectures don't all speak the same language How about something like: The SYNC_CORE operation causes all threads in the caller's address space (including the caller) to execute an architecture-defined barrier operation. membarrier() will ensure that this barrier is executed at a time such that all data writes done by the calling thread before membarrier() are made visible by the barrier. Additional architecture-dependent cache management operations may be required to use this for JIT code. x86: SYNC_CORE executes a barrier that will cause subsequent instruction fetches to observe prior writes. Currently this will be a "serializing" instruction, but, if future improved CPU documentation becomes available and relaxes this requirement, the barrier may change. The kernel guarantees that writing new or modified instructions to normal memory (and issuing SFENCE if the writes were non-temporal) then doing a membarrier SYNC_CORE operation is sufficient to cause all threads in the caller's address space to execute the new or modified instructions. This is true regardless of whether or not those instructions are written at the same virtual address from which they are subsequently executed. No additional cache management is required on x86. arm: Something about the cache management syscalls. arm64: Ditto powerpc: I have no idea. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel