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 25BE4C433E6 for ; Tue, 29 Dec 2020 00:37:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E02AD207CF for ; Tue, 29 Dec 2020 00:37:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730549AbgL2AhH (ORCPT ); Mon, 28 Dec 2020 19:37:07 -0500 Received: from mail.kernel.org ([198.145.29.99]:46652 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730191AbgL2AhG (ORCPT ); Mon, 28 Dec 2020 19:37:06 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id F27B8221F8 for ; Tue, 29 Dec 2020 00:36:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609202185; bh=VX6lw2IJ/z/WjavzOW0lIGvJ2PJ7vI+cPiWmgFXCEi4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=klsW25bgbw2Tvtt4HCiG69FQv4hapU7eCpnsPT82tb4h4tFP+WN5MPXW0TPAeMUpE W1Bb4qLn/j8DCfX8hQQAiqGNj6lXOleMlM9evE8WGtODI/8ERWwzB3l6X0EzFK+iXl aG8FI0bAypxmmj1Cy8x44bo2yHoNpPH/NHkJKPAgCIV0dUb1vP3BbS8Q9dZ/pLQvqM JZtvRnlxRT1vQPPEfvC8rvHwMH6aovwMSGTBsxsIRvSryxDzpGLkz8A85O/i6JFVz8 7hZEJ81kX43ATdY1/1QvFDU5BZScQNXGrav0we/3oQWufomEIHb9hrB9kNKBfqj888 5Bi+xNXHb2INg== Received: by mail-wr1-f41.google.com with SMTP id m5so12780453wrx.9 for ; Mon, 28 Dec 2020 16:36:24 -0800 (PST) X-Gm-Message-State: AOAM532+J6HOZugLpQQVCRWpLr4o2mE1IMKNFOg6R/RjboAEi+7bq0Qu lRYAaWhauq9PBBqvsZAPVpdMSNp2WffOBeB3pEjAxA== X-Google-Smtp-Source: ABdhPJztatywU6YOwSIVKLEbxZBNtEBa5iKSCwJTklOqEdD0ibLsWDGLhd7b2Cd3Fhyjte4DtXNSQn+FYl2eIOzIjDE= X-Received: by 2002:a5d:43c3:: with SMTP id v3mr52282122wrr.184.1609202183585; Mon, 28 Dec 2020 16:36:23 -0800 (PST) MIME-Version: 1.0 References: <1609199804.yrsu9vagzk.astroid@bobo.none> In-Reply-To: <1609199804.yrsu9vagzk.astroid@bobo.none> From: Andy Lutomirski Date: Mon, 28 Dec 2020 16:36:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Nicholas Piggin Cc: Andy Lutomirski , Mathieu Desnoyers , X86 ML , Arnd Bergmann , Benjamin Herrenschmidt , Catalin Marinas , linux-arm-kernel , LKML , linuxppc-dev , Michael Ellerman , Paul Mackerras , stable , Will Deacon 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 4:11 PM Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 28, 2020 4:28 am: > > The old sync_core_before_usermode() comments said that a non-icache-syncing > > return-to-usermode instruction is x86-specific and that all other > > architectures automatically notice cross-modified code on return to > > userspace. Based on my general understanding of how CPUs work and based on > > my atttempt to read the ARM manual, this is not true at all. In fact, x86 > > seems to be a bit of an anomaly in the other direction: x86's IRET is > > unusually heavyweight for a return-to-usermode instruction. > > "sync_core_before_usermode" as I've said says nothing to arch, or to the > scheduler, or to membarrier. Agreed. My patch tries to fix this. I agree that the name is bad and could be improved further. We should define what membarrier(...SYNC_CORE) actually does and have arch hooks to make it happen. > > So let's drop any pretense that we can have a generic way implementation > > behind membarrier's SYNC_CORE flush and require all architectures that opt > > in to supply their own. This means x86, arm64, and powerpc for now. Let's > > also rename the function from sync_core_before_usermode() to > > membarrier_sync_core_before_usermode() because the precise flushing details > > may very well be specific to membarrier, and even the concept of > > "sync_core" in the kernel is mostly an x86-ism. > > The concept of "sync_core" (x86: serializing instruction, powerpc: context > synchronizing instruction, etc) is not an x86-ism at all. x86 just wanted > to add a serializing instruction to generic code so it grew this nasty API, > but the concept applies broadly. I mean that the mapping from the name "sync_core" to its semantics is x86 only. The string "sync_core" appears in the kernel only in arch/x86, membarrier code, membarrier docs, and a single SGI driver that is x86-only. Sure, the idea of serializing things is fairly generic, but exactly what operations serialize what, when things need serialization, etc is quite architecture specific. Heck, on 486 you serialize the instruction stream with JMP. > > +static inline void membarrier_sync_core_before_usermode(void) > > +{ > > + /* > > + * XXX: I know basically nothing about powerpc cache management. > > + * Is this correct? > > + */ > > + isync(); > > This is not about memory ordering or cache management, it's about > pipeline management. Powerpc's return to user mode serializes the > CPU (aka the hardware thread, _not_ the core; another wrongness of > the name, but AFAIKS the HW thread is what is required for > membarrier). So this is wrong, powerpc needs nothing here. Fair enough. I'm happy to defer to you on the powerpc details. In any case, this just illustrates that we need feedback from a person who knows more about ARM64 than I do. 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 70838C433DB for ; Tue, 29 Dec 2020 00:38:20 +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 88D7C20719 for ; Tue, 29 Dec 2020 00:38:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88D7C20719 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 4D4bB1637QzDqDM for ; Tue, 29 Dec 2020 11:38:17 +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=klsW25bg; 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 4D4b7w0MQszDqCC for ; Tue, 29 Dec 2020 11:36:27 +1100 (AEDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id 00A1822225 for ; Tue, 29 Dec 2020 00:36:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609202185; bh=VX6lw2IJ/z/WjavzOW0lIGvJ2PJ7vI+cPiWmgFXCEi4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=klsW25bgbw2Tvtt4HCiG69FQv4hapU7eCpnsPT82tb4h4tFP+WN5MPXW0TPAeMUpE W1Bb4qLn/j8DCfX8hQQAiqGNj6lXOleMlM9evE8WGtODI/8ERWwzB3l6X0EzFK+iXl aG8FI0bAypxmmj1Cy8x44bo2yHoNpPH/NHkJKPAgCIV0dUb1vP3BbS8Q9dZ/pLQvqM JZtvRnlxRT1vQPPEfvC8rvHwMH6aovwMSGTBsxsIRvSryxDzpGLkz8A85O/i6JFVz8 7hZEJ81kX43ATdY1/1QvFDU5BZScQNXGrav0we/3oQWufomEIHb9hrB9kNKBfqj888 5Bi+xNXHb2INg== Received: by mail-wr1-f42.google.com with SMTP id t30so12846515wrb.0 for ; Mon, 28 Dec 2020 16:36:24 -0800 (PST) X-Gm-Message-State: AOAM531VhI87RLBzsDJFDO+aVabwO3TE6tWf6pCAiFdybi37h7dcEbuz I35EgfjuMLKimjXm4/SCYbWunSRxEoJTs+pfWy+3gA== X-Google-Smtp-Source: ABdhPJztatywU6YOwSIVKLEbxZBNtEBa5iKSCwJTklOqEdD0ibLsWDGLhd7b2Cd3Fhyjte4DtXNSQn+FYl2eIOzIjDE= X-Received: by 2002:a5d:43c3:: with SMTP id v3mr52282122wrr.184.1609202183585; Mon, 28 Dec 2020 16:36:23 -0800 (PST) MIME-Version: 1.0 References: <1609199804.yrsu9vagzk.astroid@bobo.none> In-Reply-To: <1609199804.yrsu9vagzk.astroid@bobo.none> From: Andy Lutomirski Date: Mon, 28 Dec 2020 16:36:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Nicholas Piggin 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: Arnd Bergmann , X86 ML , LKML , stable , Will Deacon , Mathieu Desnoyers , Andy Lutomirski , Catalin Marinas , Paul Mackerras , linuxppc-dev , 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 4:11 PM Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 28, 2020 4:28 am: > > The old sync_core_before_usermode() comments said that a non-icache-syncing > > return-to-usermode instruction is x86-specific and that all other > > architectures automatically notice cross-modified code on return to > > userspace. Based on my general understanding of how CPUs work and based on > > my atttempt to read the ARM manual, this is not true at all. In fact, x86 > > seems to be a bit of an anomaly in the other direction: x86's IRET is > > unusually heavyweight for a return-to-usermode instruction. > > "sync_core_before_usermode" as I've said says nothing to arch, or to the > scheduler, or to membarrier. Agreed. My patch tries to fix this. I agree that the name is bad and could be improved further. We should define what membarrier(...SYNC_CORE) actually does and have arch hooks to make it happen. > > So let's drop any pretense that we can have a generic way implementation > > behind membarrier's SYNC_CORE flush and require all architectures that opt > > in to supply their own. This means x86, arm64, and powerpc for now. Let's > > also rename the function from sync_core_before_usermode() to > > membarrier_sync_core_before_usermode() because the precise flushing details > > may very well be specific to membarrier, and even the concept of > > "sync_core" in the kernel is mostly an x86-ism. > > The concept of "sync_core" (x86: serializing instruction, powerpc: context > synchronizing instruction, etc) is not an x86-ism at all. x86 just wanted > to add a serializing instruction to generic code so it grew this nasty API, > but the concept applies broadly. I mean that the mapping from the name "sync_core" to its semantics is x86 only. The string "sync_core" appears in the kernel only in arch/x86, membarrier code, membarrier docs, and a single SGI driver that is x86-only. Sure, the idea of serializing things is fairly generic, but exactly what operations serialize what, when things need serialization, etc is quite architecture specific. Heck, on 486 you serialize the instruction stream with JMP. > > +static inline void membarrier_sync_core_before_usermode(void) > > +{ > > + /* > > + * XXX: I know basically nothing about powerpc cache management. > > + * Is this correct? > > + */ > > + isync(); > > This is not about memory ordering or cache management, it's about > pipeline management. Powerpc's return to user mode serializes the > CPU (aka the hardware thread, _not_ the core; another wrongness of > the name, but AFAIKS the HW thread is what is required for > membarrier). So this is wrong, powerpc needs nothing here. Fair enough. I'm happy to defer to you on the powerpc details. In any case, this just illustrates that we need feedback from a person who knows more about ARM64 than I do. 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, URIBL_BLOCKED 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 1542DC433DB for ; Tue, 29 Dec 2020 00:38:13 +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 BD87B20719 for ; Tue, 29 Dec 2020 00:38:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD87B20719 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=FfLr187Bozl3yzjO7y4UOS3C6ZAqi/zbB+vxMlYPnxY=; b=PNPKx1LBBuTf+l7IeRO0pE9gX lQqWIBsTZ7I6bWi0FE17UNNv5Z7YoOh80Oz+KlWyLIf+e64NIDvN02V/7qzU3GacHodzTvGTENdSD 5s9qUR3SHAO0uiWrvve9LIyP/uZn9ciowJp+pW//XbcbY6wJY4wmVV5eAOTLV5I+DBMCVkzKmJjTW 8mfckERoYvOkC/7t1CdrpTR7789EnhhwNfAsGU+C7RXdeTYjvAFu1j9JjDDWN3LZGQZ9sKojZOvPN cQ4gVqKVKeAbMuugWQKXe+1XMnrzd6a/hGEyz9+TKHE/UyG5Jbwubj+Gf8YDlAM3C82Opwiv22Ul7 boBsSYFAQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ku302-0008Ls-8j; Tue, 29 Dec 2020 00:36:30 +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 1ku2zx-0008KY-Ns for linux-arm-kernel@lists.infradead.org; Tue, 29 Dec 2020 00:36:27 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E9BBC207CF for ; Tue, 29 Dec 2020 00:36:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609202185; bh=VX6lw2IJ/z/WjavzOW0lIGvJ2PJ7vI+cPiWmgFXCEi4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=klsW25bgbw2Tvtt4HCiG69FQv4hapU7eCpnsPT82tb4h4tFP+WN5MPXW0TPAeMUpE W1Bb4qLn/j8DCfX8hQQAiqGNj6lXOleMlM9evE8WGtODI/8ERWwzB3l6X0EzFK+iXl aG8FI0bAypxmmj1Cy8x44bo2yHoNpPH/NHkJKPAgCIV0dUb1vP3BbS8Q9dZ/pLQvqM JZtvRnlxRT1vQPPEfvC8rvHwMH6aovwMSGTBsxsIRvSryxDzpGLkz8A85O/i6JFVz8 7hZEJ81kX43ATdY1/1QvFDU5BZScQNXGrav0we/3oQWufomEIHb9hrB9kNKBfqj888 5Bi+xNXHb2INg== Received: by mail-wr1-f45.google.com with SMTP id q18so12854629wrn.1 for ; Mon, 28 Dec 2020 16:36:24 -0800 (PST) X-Gm-Message-State: AOAM531AKy7BqwLE8hg/a6Oh7obxhJCa1Nbla4GqBNQ/eVzh+A2OJHX+ GvpLq6goQtY9vXc/TiktVlf09wUHa2xe+UxwNn7P/g== X-Google-Smtp-Source: ABdhPJztatywU6YOwSIVKLEbxZBNtEBa5iKSCwJTklOqEdD0ibLsWDGLhd7b2Cd3Fhyjte4DtXNSQn+FYl2eIOzIjDE= X-Received: by 2002:a5d:43c3:: with SMTP id v3mr52282122wrr.184.1609202183585; Mon, 28 Dec 2020 16:36:23 -0800 (PST) MIME-Version: 1.0 References: <1609199804.yrsu9vagzk.astroid@bobo.none> In-Reply-To: <1609199804.yrsu9vagzk.astroid@bobo.none> From: Andy Lutomirski Date: Mon, 28 Dec 2020 16:36:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Nicholas Piggin X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201228_193625_941035_C87EAB38 X-CRM114-Status: GOOD ( 26.44 ) 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: Arnd Bergmann , Benjamin Herrenschmidt , X86 ML , LKML , stable , Will Deacon , Mathieu Desnoyers , Michael Ellerman , Andy Lutomirski , Catalin Marinas , Paul Mackerras , linuxppc-dev , 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 4:11 PM Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 28, 2020 4:28 am: > > The old sync_core_before_usermode() comments said that a non-icache-syncing > > return-to-usermode instruction is x86-specific and that all other > > architectures automatically notice cross-modified code on return to > > userspace. Based on my general understanding of how CPUs work and based on > > my atttempt to read the ARM manual, this is not true at all. In fact, x86 > > seems to be a bit of an anomaly in the other direction: x86's IRET is > > unusually heavyweight for a return-to-usermode instruction. > > "sync_core_before_usermode" as I've said says nothing to arch, or to the > scheduler, or to membarrier. Agreed. My patch tries to fix this. I agree that the name is bad and could be improved further. We should define what membarrier(...SYNC_CORE) actually does and have arch hooks to make it happen. > > So let's drop any pretense that we can have a generic way implementation > > behind membarrier's SYNC_CORE flush and require all architectures that opt > > in to supply their own. This means x86, arm64, and powerpc for now. Let's > > also rename the function from sync_core_before_usermode() to > > membarrier_sync_core_before_usermode() because the precise flushing details > > may very well be specific to membarrier, and even the concept of > > "sync_core" in the kernel is mostly an x86-ism. > > The concept of "sync_core" (x86: serializing instruction, powerpc: context > synchronizing instruction, etc) is not an x86-ism at all. x86 just wanted > to add a serializing instruction to generic code so it grew this nasty API, > but the concept applies broadly. I mean that the mapping from the name "sync_core" to its semantics is x86 only. The string "sync_core" appears in the kernel only in arch/x86, membarrier code, membarrier docs, and a single SGI driver that is x86-only. Sure, the idea of serializing things is fairly generic, but exactly what operations serialize what, when things need serialization, etc is quite architecture specific. Heck, on 486 you serialize the instruction stream with JMP. > > +static inline void membarrier_sync_core_before_usermode(void) > > +{ > > + /* > > + * XXX: I know basically nothing about powerpc cache management. > > + * Is this correct? > > + */ > > + isync(); > > This is not about memory ordering or cache management, it's about > pipeline management. Powerpc's return to user mode serializes the > CPU (aka the hardware thread, _not_ the core; another wrongness of > the name, but AFAIKS the HW thread is what is required for > membarrier). So this is wrong, powerpc needs nothing here. Fair enough. I'm happy to defer to you on the powerpc details. In any case, this just illustrates that we need feedback from a person who knows more about ARM64 than I do. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel