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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 5405EC433E9 for ; Wed, 30 Dec 2020 02:34:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1697E207BC for ; Wed, 30 Dec 2020 02:34:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726365AbgL3Cdv (ORCPT ); Tue, 29 Dec 2020 21:33:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726325AbgL3Cdu (ORCPT ); Tue, 29 Dec 2020 21:33:50 -0500 Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46D53C06179C; Tue, 29 Dec 2020 18:33:10 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id c12so8966254pfo.10; Tue, 29 Dec 2020 18:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=PfIl0EjmWMxnSF+EOk80ZAbjAPzwaEf3qyLecMl/XRc=; b=nDaFL5lxYCUZxEPCVotfMjioI5BLNIhicG92GYRl+bW9o7TrWxGxPe0PqDXDUdvxGL ovvYBF0bISGn/Zpzf1pyHYOdLFAxrz3UfAR1lXz51N/K03KuWE71VFegfMD1DDIP/drp KUhqJ9Fn3WcSfrmIuDfPZ/QOnNSC22L/Z/ORAmWhZN1D2xASIe52OucM/qXVfSayaGAT 57fbAo1T7kYgyhJGZ9Evd5nqFiAIc1edFYHuzkkIxctQBFyOJMPSHfXVdoKBjZA9clIV kEZ8gdlTRJigmHZJrUOZzCZPE80ijU9zMl4P4nZYuEkJlMxEzvQaP8bXxzoxR5aFvcz5 +Drg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=PfIl0EjmWMxnSF+EOk80ZAbjAPzwaEf3qyLecMl/XRc=; b=R6NiuCYK4Ut9dRe3OD4qgs8HrMmZEUHke/1bbzKnnsGMJ20knc4qNRR4hPm5K/Wsad 2zc2F16BJ533Q0I4JJr/xLNLAAnjlrmWYOqA3kZcwQ4wdKLKY99WVUilz8XOZAgAWt8I P04aQ6HaTkn/i686C/eHr977CKP2EqUXveXjXa6MNkzgdfrLaCQxKJ8yY3X7s8r5zx+i m5Oirx2CQD7Rr48DOCH7705mJs0C/PsY1loSHUyjTWJBEL6yv1XKqNVuo+FBMfR6wshM Q5C4vsHM4bzRG5pEamm7dPwEBqWoPlWKRly71qY5qzkAsTiJi1HV+jz/tmIJKZb3jcxB wWbQ== X-Gm-Message-State: AOAM532bt8w44ndQjX0cW6qCfB8jp3FwC+PXlkTaHlfhlYuF8Jp0cj9I a6zdbSEuYn8rN4buCSpDLbs= X-Google-Smtp-Source: ABdhPJxrOi9/gzDcjAgCtPx6FdiSP/JyedYlzSeHtVs/umobQsm2fE2URPOa8A0aW0Z8ZJFEkl2N/w== X-Received: by 2002:a63:c04b:: with SMTP id z11mr50606521pgi.74.1609295589813; Tue, 29 Dec 2020 18:33:09 -0800 (PST) Received: from localhost (193-116-97-30.tpgi.com.au. [193.116.97.30]) by smtp.gmail.com with ESMTPSA id 6sm39988438pfj.216.2020.12.29.18.33.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Dec 2020 18:33:08 -0800 (PST) Date: Wed, 30 Dec 2020 12:33:02 +1000 From: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Russell King - ARM Linux admin Cc: Arnd Bergmann , Benjamin Herrenschmidt , Catalin Marinas , Jann Horn , linux-arm-kernel , linux-kernel , linuxppc-dev , Andy Lutomirski , Mathieu Desnoyers , Michael Ellerman , paulmck , Paul Mackerras , Peter Zijlstra , stable , Will Deacon , x86 References: <20201228102537.GG1551@shell.armlinux.org.uk> <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> In-Reply-To: <20201229104456.GK1551@shell.armlinux.org.uk> MIME-Version: 1.0 Message-Id: <1609290821.wrfh89v23a.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). >=20 > 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 portab= le. On Linux, this call first appeared on the MIPS architecture, but no= wa=E2=80=90 days, Linux provides a cacheflush() system call on some other archit= ec=E2=80=90 tures, but with different arguments. What a disaster. Another badly designed interface, although it didn't=20 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=20 have thought for more than 2 minutes about it. Sigh. >=20 > Sadly, because it's existed for 20+ years, and it has historically been > sufficient for other purposes too, it has seen quite a bit of abuse > despite its design purpose not changing - it's been used by graphics > drivers for example. They quickly learnt the error of their ways with > ARMv6+, since it does not do sufficient for their purposes given the > cache architectures found there. >=20 > Let's not go around redesigning this after twenty odd years, requiring > a hell of a lot of pain to users. This interface is called by code > generated by GCC, so to change it you're looking at patching GCC as > well as the kernel, and you basically will make new programs > incompatible with older kernels - very bad news for users. For something to be redesigned it had to have been designed in the first=20 place, so there is no danger of that don't worry... But no I never=20 suggested making incompatible changes to any existing system call, I=20 said "re-documented". And yes I said deprecated but in Linux that really=20 means kept indefinitely. If ARM, MIPS, 68k etc programs and toolchains keep using what they are=20 using it'll keep working no problem. The point is we're growing new interfaces, and making the same mistakes.=20 It's not portable (ARCH_HAS_MEMBARRIER_SYNC_CORE), it's also specified=20 in terms of low level processor operations rather than higher level=20 intent, and also is not sufficient for self-modifying code (without=20 additional cache flush on some processors). The application wants a call that says something like "memory modified=20 before the call will be visible as instructions (including illegal=20 instructions) by all threads in the program after the system call=20 returns, and no threads will be subject to any effects of executing the=20 previous contents of that memory. So I think the basics are simple (although should confirm with some JIT=20 and debugger etc developers, and not just Android mind you). There are=20 some complications in details, address ranges, virtual/physical, thread=20 local vs process vs different process or system-wide, memory ordering=20 and propagation of i and d sides, etc. But that can be worked through,=20 erring on the side of sanity rather than pointless micro-optmisations. Thanks, Nick 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=-0.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 B4EB3C433E0 for ; Wed, 30 Dec 2020 02:35:19 +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 DEE0C207BC for ; Wed, 30 Dec 2020 02:35:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DEE0C207BC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 4D5FkW6NdZzDqJg for ; Wed, 30 Dec 2020 13:35:15 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::533; helo=mail-pg1-x533.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=nDaFL5lx; dkim-atps=neutral Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4D5FhB4ntgzDqGb for ; Wed, 30 Dec 2020 13:33:13 +1100 (AEDT) Received: by mail-pg1-x533.google.com with SMTP id w5so10571628pgj.3 for ; Tue, 29 Dec 2020 18:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=PfIl0EjmWMxnSF+EOk80ZAbjAPzwaEf3qyLecMl/XRc=; b=nDaFL5lxYCUZxEPCVotfMjioI5BLNIhicG92GYRl+bW9o7TrWxGxPe0PqDXDUdvxGL ovvYBF0bISGn/Zpzf1pyHYOdLFAxrz3UfAR1lXz51N/K03KuWE71VFegfMD1DDIP/drp KUhqJ9Fn3WcSfrmIuDfPZ/QOnNSC22L/Z/ORAmWhZN1D2xASIe52OucM/qXVfSayaGAT 57fbAo1T7kYgyhJGZ9Evd5nqFiAIc1edFYHuzkkIxctQBFyOJMPSHfXVdoKBjZA9clIV kEZ8gdlTRJigmHZJrUOZzCZPE80ijU9zMl4P4nZYuEkJlMxEzvQaP8bXxzoxR5aFvcz5 +Drg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=PfIl0EjmWMxnSF+EOk80ZAbjAPzwaEf3qyLecMl/XRc=; b=QCDVh8NzrThiMxT4jkuJ/VQEdWYR4to6N0IUZiZD8GvSeZWV9W/XaC3v5CzkgbqYFs wwi5Bj9ORb5UKMDLhDt1dLn4BClFiVo05J09WQafBV9Nl+y/xLTIUMKTkSRceZZmiri6 k3bbSV4XzGczZ2Cnk0mGE2yUNYiluCB49dsjsGG+mbmeZ/P6MCRQ6/+5SEBqD+GVxQzB fLWRKz5xldU7EI2Qlzat+Id4NDyy8mwizogq2SfEYz3jCk36nTDbpGlNAniXcuMDSfmv q0eR5F/obQ67v3y+Isca0sJWEyfj6r64sRKHyJEHuSWaCkfPw0HBj9vFsHp59Clw8/vj +jLQ== X-Gm-Message-State: AOAM531uue46MVY4bVAe4/ezeWmp5mrIyfEyn3rRE6o0BVGfE33/2BXR NvMKaHq+Dsto8MdNKXowczI= X-Google-Smtp-Source: ABdhPJxrOi9/gzDcjAgCtPx6FdiSP/JyedYlzSeHtVs/umobQsm2fE2URPOa8A0aW0Z8ZJFEkl2N/w== X-Received: by 2002:a63:c04b:: with SMTP id z11mr50606521pgi.74.1609295589813; Tue, 29 Dec 2020 18:33:09 -0800 (PST) Received: from localhost (193-116-97-30.tpgi.com.au. [193.116.97.30]) by smtp.gmail.com with ESMTPSA id 6sm39988438pfj.216.2020.12.29.18.33.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Dec 2020 18:33:08 -0800 (PST) Date: Wed, 30 Dec 2020 12:33:02 +1000 From: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Russell King - ARM Linux admin References: <20201228102537.GG1551@shell.armlinux.org.uk> <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> In-Reply-To: <20201229104456.GK1551@shell.armlinux.org.uk> MIME-Version: 1.0 Message-Id: <1609290821.wrfh89v23a.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: paulmck , Arnd Bergmann , Jann Horn , Peter Zijlstra , x86 , linux-kernel , 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" 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). >=20 > 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 portab= le. On Linux, this call first appeared on the MIPS architecture, but no= wa=E2=80=90 days, Linux provides a cacheflush() system call on some other archit= ec=E2=80=90 tures, but with different arguments. What a disaster. Another badly designed interface, although it didn't=20 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=20 have thought for more than 2 minutes about it. Sigh. >=20 > Sadly, because it's existed for 20+ years, and it has historically been > sufficient for other purposes too, it has seen quite a bit of abuse > despite its design purpose not changing - it's been used by graphics > drivers for example. They quickly learnt the error of their ways with > ARMv6+, since it does not do sufficient for their purposes given the > cache architectures found there. >=20 > Let's not go around redesigning this after twenty odd years, requiring > a hell of a lot of pain to users. This interface is called by code > generated by GCC, so to change it you're looking at patching GCC as > well as the kernel, and you basically will make new programs > incompatible with older kernels - very bad news for users. For something to be redesigned it had to have been designed in the first=20 place, so there is no danger of that don't worry... But no I never=20 suggested making incompatible changes to any existing system call, I=20 said "re-documented". And yes I said deprecated but in Linux that really=20 means kept indefinitely. If ARM, MIPS, 68k etc programs and toolchains keep using what they are=20 using it'll keep working no problem. The point is we're growing new interfaces, and making the same mistakes.=20 It's not portable (ARCH_HAS_MEMBARRIER_SYNC_CORE), it's also specified=20 in terms of low level processor operations rather than higher level=20 intent, and also is not sufficient for self-modifying code (without=20 additional cache flush on some processors). The application wants a call that says something like "memory modified=20 before the call will be visible as instructions (including illegal=20 instructions) by all threads in the program after the system call=20 returns, and no threads will be subject to any effects of executing the=20 previous contents of that memory. So I think the basics are simple (although should confirm with some JIT=20 and debugger etc developers, and not just Android mind you). There are=20 some complications in details, address ranges, virtual/physical, thread=20 local vs process vs different process or system-wide, memory ordering=20 and propagation of i and d sides, etc. But that can be worked through,=20 erring on the side of sanity rather than pointless micro-optmisations. Thanks, Nick 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=-0.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 646B4C433E0 for ; Wed, 30 Dec 2020 02:34:41 +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 1F396207BC for ; Wed, 30 Dec 2020 02:34:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F396207BC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:Message-Id:MIME-Version:In-Reply-To:References:To: Subject:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2G3OAjbI1R/2FfFjD0KMSxlBoT7ZP8dT1Ts3Yu/36j4=; b=DD11ITyKA0vXpU2OGKB+OzJkW gGEQS6QeReqsJyelkjuWx+aOgMKhkvwjHi9G7U1J3B2JLK1ADmPGuOq/LT+VMWrDbEPPSvziEKeHO UaQ8Raq6gHpqpbsSxueJz9x2yHzSqDmiYl+YFfyXEOb82ytnexmpdZzgeu/iJsGsbRzbQxG9LKHZk UuVjwHmSubki48G9AC9B4dKTLlQ1MSAwIqC2CKlvg4rpmdzseStg1WgHL3Ra/uIDUKTZ3Q8ZTFpjK RqDzTVj12EA1zMaDg295FI0/vJrfqi6w21IYGnJaS8ejWZTqL4ss9BkrDt4dPkisWb51gtVm7C/hZ IKKMMrXpA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kuRIa-0005Ds-1l; Wed, 30 Dec 2020 02:33:16 +0000 Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kuRIX-0005Ck-Em for linux-arm-kernel@lists.infradead.org; Wed, 30 Dec 2020 02:33:14 +0000 Received: by mail-pg1-x52f.google.com with SMTP id i5so10574680pgo.1 for ; Tue, 29 Dec 2020 18:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=PfIl0EjmWMxnSF+EOk80ZAbjAPzwaEf3qyLecMl/XRc=; b=nDaFL5lxYCUZxEPCVotfMjioI5BLNIhicG92GYRl+bW9o7TrWxGxPe0PqDXDUdvxGL ovvYBF0bISGn/Zpzf1pyHYOdLFAxrz3UfAR1lXz51N/K03KuWE71VFegfMD1DDIP/drp KUhqJ9Fn3WcSfrmIuDfPZ/QOnNSC22L/Z/ORAmWhZN1D2xASIe52OucM/qXVfSayaGAT 57fbAo1T7kYgyhJGZ9Evd5nqFiAIc1edFYHuzkkIxctQBFyOJMPSHfXVdoKBjZA9clIV kEZ8gdlTRJigmHZJrUOZzCZPE80ijU9zMl4P4nZYuEkJlMxEzvQaP8bXxzoxR5aFvcz5 +Drg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=PfIl0EjmWMxnSF+EOk80ZAbjAPzwaEf3qyLecMl/XRc=; b=l7neLo3LxzoEa+aXad2Ou8/DOU1Shvw/1Rb/pFe06r0aNDyH5nlcBymsQdVJenVdGs c6BVMpofm5l1uPEyOwYsSbx9M5WhE2ibycXCdl2zgvIpKhr6OLba1eS4yWyaTfPHEV4D +7ezTu/rnIdtdWnJymGQhD0IQV5/9z1KS7nWMYpy91kgtO5Oepo0iIe9BvOAtqtzs0uN EEmPxMh8GXAsa3YlnRWryCR6dMUCpBSzo3LRvT2i37HLkJNKZe1qhzLS8FPrHhe6LqaL 9xxyx5eh72GlUZUukQW0jHg3Mgl9ixY1NIe6Dg7BXDP2iOYBmXXluvxrID4GADi/KGuk pEgA== X-Gm-Message-State: AOAM532RquQEuAk8Os3iVAGXhj8bDnf6ufRzIt4u9M0OY3ejWQnP9+lU IEjf4DaL87XIX15R9ShRg1g= X-Google-Smtp-Source: ABdhPJxrOi9/gzDcjAgCtPx6FdiSP/JyedYlzSeHtVs/umobQsm2fE2URPOa8A0aW0Z8ZJFEkl2N/w== X-Received: by 2002:a63:c04b:: with SMTP id z11mr50606521pgi.74.1609295589813; Tue, 29 Dec 2020 18:33:09 -0800 (PST) Received: from localhost (193-116-97-30.tpgi.com.au. [193.116.97.30]) by smtp.gmail.com with ESMTPSA id 6sm39988438pfj.216.2020.12.29.18.33.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Dec 2020 18:33:08 -0800 (PST) Date: Wed, 30 Dec 2020 12:33:02 +1000 From: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Russell King - ARM Linux admin References: <20201228102537.GG1551@shell.armlinux.org.uk> <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> In-Reply-To: <20201229104456.GK1551@shell.armlinux.org.uk> MIME-Version: 1.0 Message-Id: <1609290821.wrfh89v23a.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201229_213313_518586_00690597 X-CRM114-Status: GOOD ( 22.82 ) 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: 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org RXhjZXJwdHMgZnJvbSBSdXNzZWxsIEtpbmcgLSBBUk0gTGludXggYWRtaW4ncyBtZXNzYWdlIG9m IERlY2VtYmVyIDI5LCAyMDIwIDg6NDQgcG06Cj4gT24gVHVlLCBEZWMgMjksIDIwMjAgYXQgMDE6 MDk6MTJQTSArMTAwMCwgTmljaG9sYXMgUGlnZ2luIHdyb3RlOgo+PiBJIHRoaW5rIGl0IHNob3Vs ZCBjZXJ0YWlubHkgYmUgZG9jdW1lbnRlZCBpbiB0ZXJtcyBvZiB3aGF0IGd1YXJhbnRlZXMKPj4g aXQgcHJvdmlkZXMgdG8gYXBwbGljYXRpb24sIF9ub3RfIHRoZSBraW5kcyBvZiBpbnN0cnVjdGlv bnMgaXQgbWF5IG9yCj4+IG1heSBub3QgaW5kdWNlIHRoZSBjb3JlIHRvIGV4ZWN1dGUuIEFuZCBp ZiBleGlzdGluZyBBUEkgY2FuJ3QgYmUKPj4gcmUtZG9jdW1lbnRlZCBzYW5lbHksIHRoZW4gZGVw cmVjYXRkIGFuZCBuZXcgb25lcyBhZGRlZCB0aGF0IERUUlQuCj4+IFBvc3NpYmx5IHVuZGVyIGEg bmV3IHN5c3RlbSBjYWxsLCBpZiBhcmNoJ3MgbGlrZSBBUk0gd2FudCBhIHJhbmdlCj4+IGZsdXNo IGFuZCB3ZSBkb24ndCB3YW50IHRvIGV4cGFuZCB0aGUgbXVsdGlwbGV4aW5nIGJlaGF2aW91ciBv Zgo+PiBtZW1iYXJyaWVyIGV2ZW4gbW9yZSAoc2lnaCkuCj4gCj4gVGhlIDMyLWJpdCBBUk0gc3lz X2NhY2hlZmx1c2goKSBpcyB0aGVyZSBvbmx5IHRvIHN1cHBvcnQgc2VsZi1tb2RpZnlpbmcKPiBj b2RlLCBhbmQgdGFrZXMgd2hhdGV2ZXIgYWN0aW9ucyBhcmUgbmVjZXNzYXJ5IHRvIHN1cHBvcnQg dGhhdC4KPiBFeGFjdGx5IHdoYXQgYWN0aW9ucyBpdCB0YWtlcyBhcmUgY2FjaGUgaW1wbGVtZW50 YXRpb24gc3BlY2lmaWMsIGFuZAo+IHNob3VsZCBiZSBvZiBubyBjb25jZXJuIHRvIHRoZSBjYWxs ZXIsIGJ1dCB0aGUgdW5kZXJseWluZyB0aGluZyBpcy4uLgo+IGl0J3MgdG8gc3VwcG9ydCBzZWxm LW1vZGlmeWluZyBjb2RlLgoKICAgQ2F2ZWF0CiAgICAgICBjYWNoZWZsdXNoKCkgIHNob3VsZCAg bm90ICBiZSB1c2VkIGluIHByb2dyYW1zIGludGVuZGVkIHRvIGJlIHBvcnRhYmxlLgogICAgICAg T24gTGludXgsIHRoaXMgY2FsbCBmaXJzdCBhcHBlYXJlZCBvbiB0aGUgTUlQUyBhcmNoaXRlY3R1 cmUsIGJ1dCAgbm93YeKAkAogICAgICAgZGF5cywgTGludXggcHJvdmlkZXMgYSBjYWNoZWZsdXNo KCkgc3lzdGVtIGNhbGwgb24gc29tZSBvdGhlciBhcmNoaXRlY+KAkAogICAgICAgdHVyZXMsIGJ1 dCB3aXRoIGRpZmZlcmVudCBhcmd1bWVudHMuCgpXaGF0IGEgZGlzYXN0ZXIuIEFub3RoZXIgYmFk bHkgZGVzaWduZWQgaW50ZXJmYWNlLCBhbHRob3VnaCBpdCBkaWRuJ3QgCm9yaWdpbmF0ZSBpbiBM aW51eCBpdCBzb3VuZHMgbGlrZSB3ZSB3ZXJlbid0IHRvIGJlIG91dGRvbmUgc28Kd2UgbWVzc2Vk IGl0IHVwIGV2ZW4gd29yc2UuCgpmbHVzaGluZyBjYWNoZXMgaXMgbmVpdGhlciBuZWNlc3Nhcnkg bm9yIHN1ZmZpY2llbnQgZm9yIGNvZGUgbW9kaWZpY2F0aW9uCm9uIG1hbnkgcHJvY2Vzc29ycy4g TWF5YmUgc29tZSBvbGQgTUlQUyBzcGVjaWZpYyBwcml2YXRlIHRoaW5nIHdhcyBmaW5lLApidXQg Y2VydGFpbmx5IGJlZm9yZSBpdCBncmV3IHRvIG90aGVyIGFyY2hpdGVjdHVyZXMsIHNvbWVib2R5 IHNob3VsZCAKaGF2ZSB0aG91Z2h0IGZvciBtb3JlIHRoYW4gMiBtaW51dGVzIGFib3V0IGl0LiBT aWdoLgoKPiAKPiBTYWRseSwgYmVjYXVzZSBpdCdzIGV4aXN0ZWQgZm9yIDIwKyB5ZWFycywgYW5k IGl0IGhhcyBoaXN0b3JpY2FsbHkgYmVlbgo+IHN1ZmZpY2llbnQgZm9yIG90aGVyIHB1cnBvc2Vz IHRvbywgaXQgaGFzIHNlZW4gcXVpdGUgYSBiaXQgb2YgYWJ1c2UKPiBkZXNwaXRlIGl0cyBkZXNp Z24gcHVycG9zZSBub3QgY2hhbmdpbmcgLSBpdCdzIGJlZW4gdXNlZCBieSBncmFwaGljcwo+IGRy aXZlcnMgZm9yIGV4YW1wbGUuIFRoZXkgcXVpY2tseSBsZWFybnQgdGhlIGVycm9yIG9mIHRoZWly IHdheXMgd2l0aAo+IEFSTXY2Kywgc2luY2UgaXQgZG9lcyBub3QgZG8gc3VmZmljaWVudCBmb3Ig dGhlaXIgcHVycG9zZXMgZ2l2ZW4gdGhlCj4gY2FjaGUgYXJjaGl0ZWN0dXJlcyBmb3VuZCB0aGVy ZS4KPiAKPiBMZXQncyBub3QgZ28gYXJvdW5kIHJlZGVzaWduaW5nIHRoaXMgYWZ0ZXIgdHdlbnR5 IG9kZCB5ZWFycywgcmVxdWlyaW5nCj4gYSBoZWxsIG9mIGEgbG90IG9mIHBhaW4gdG8gdXNlcnMu IFRoaXMgaW50ZXJmYWNlIGlzIGNhbGxlZCBieSBjb2RlCj4gZ2VuZXJhdGVkIGJ5IEdDQywgc28g dG8gY2hhbmdlIGl0IHlvdSdyZSBsb29raW5nIGF0IHBhdGNoaW5nIEdDQyBhcwo+IHdlbGwgYXMg dGhlIGtlcm5lbCwgYW5kIHlvdSBiYXNpY2FsbHkgd2lsbCBtYWtlIG5ldyBwcm9ncmFtcwo+IGlu Y29tcGF0aWJsZSB3aXRoIG9sZGVyIGtlcm5lbHMgLSB2ZXJ5IGJhZCBuZXdzIGZvciB1c2Vycy4K CkZvciBzb21ldGhpbmcgdG8gYmUgcmVkZXNpZ25lZCBpdCBoYWQgdG8gaGF2ZSBiZWVuIGRlc2ln bmVkIGluIHRoZSBmaXJzdCAKcGxhY2UsIHNvIHRoZXJlIGlzIG5vIGRhbmdlciBvZiB0aGF0IGRv bid0IHdvcnJ5Li4uIEJ1dCBubyBJIG5ldmVyIApzdWdnZXN0ZWQgbWFraW5nIGluY29tcGF0aWJs ZSBjaGFuZ2VzIHRvIGFueSBleGlzdGluZyBzeXN0ZW0gY2FsbCwgSSAKc2FpZCAicmUtZG9jdW1l bnRlZCIuIEFuZCB5ZXMgSSBzYWlkIGRlcHJlY2F0ZWQgYnV0IGluIExpbnV4IHRoYXQgcmVhbGx5 IAptZWFucyBrZXB0IGluZGVmaW5pdGVseS4KCklmIEFSTSwgTUlQUywgNjhrIGV0YyBwcm9ncmFt cyBhbmQgdG9vbGNoYWlucyBrZWVwIHVzaW5nIHdoYXQgdGhleSBhcmUgCnVzaW5nIGl0J2xsIGtl ZXAgd29ya2luZyBubyBwcm9ibGVtLgoKVGhlIHBvaW50IGlzIHdlJ3JlIGdyb3dpbmcgbmV3IGlu dGVyZmFjZXMsIGFuZCBtYWtpbmcgdGhlIHNhbWUgbWlzdGFrZXMuIApJdCdzIG5vdCBwb3J0YWJs ZSAoQVJDSF9IQVNfTUVNQkFSUklFUl9TWU5DX0NPUkUpLCBpdCdzIGFsc28gc3BlY2lmaWVkIApp biB0ZXJtcyBvZiBsb3cgbGV2ZWwgcHJvY2Vzc29yIG9wZXJhdGlvbnMgcmF0aGVyIHRoYW4gaGln aGVyIGxldmVsIAppbnRlbnQsIGFuZCBhbHNvIGlzIG5vdCBzdWZmaWNpZW50IGZvciBzZWxmLW1v ZGlmeWluZyBjb2RlICh3aXRob3V0IAphZGRpdGlvbmFsIGNhY2hlIGZsdXNoIG9uIHNvbWUgcHJv Y2Vzc29ycykuCgpUaGUgYXBwbGljYXRpb24gd2FudHMgYSBjYWxsIHRoYXQgc2F5cyBzb21ldGhp bmcgbGlrZSAibWVtb3J5IG1vZGlmaWVkIApiZWZvcmUgdGhlIGNhbGwgd2lsbCBiZSB2aXNpYmxl IGFzIGluc3RydWN0aW9ucyAoaW5jbHVkaW5nIGlsbGVnYWwgCmluc3RydWN0aW9ucykgYnkgYWxs IHRocmVhZHMgaW4gdGhlIHByb2dyYW0gYWZ0ZXIgdGhlIHN5c3RlbSBjYWxsIApyZXR1cm5zLCBh bmQgbm8gdGhyZWFkcyB3aWxsIGJlIHN1YmplY3QgdG8gYW55IGVmZmVjdHMgb2YgZXhlY3V0aW5n IHRoZSAKcHJldmlvdXMgY29udGVudHMgb2YgdGhhdCBtZW1vcnkuCgpTbyBJIHRoaW5rIHRoZSBi YXNpY3MgYXJlIHNpbXBsZSAoYWx0aG91Z2ggc2hvdWxkIGNvbmZpcm0gd2l0aCBzb21lIEpJVCAK YW5kIGRlYnVnZ2VyIGV0YyBkZXZlbG9wZXJzLCBhbmQgbm90IGp1c3QgQW5kcm9pZCBtaW5kIHlv dSkuIFRoZXJlIGFyZSAKc29tZSBjb21wbGljYXRpb25zIGluIGRldGFpbHMsIGFkZHJlc3MgcmFu Z2VzLCB2aXJ0dWFsL3BoeXNpY2FsLCB0aHJlYWQgCmxvY2FsIHZzIHByb2Nlc3MgdnMgZGlmZmVy ZW50IHByb2Nlc3Mgb3Igc3lzdGVtLXdpZGUsIG1lbW9yeSBvcmRlcmluZyAKYW5kIHByb3BhZ2F0 aW9uIG9mIGkgYW5kIGQgc2lkZXMsIGV0Yy4gQnV0IHRoYXQgY2FuIGJlIHdvcmtlZCB0aHJvdWdo LCAKZXJyaW5nIG9uIHRoZSBzaWRlIG9mIHNhbml0eSByYXRoZXIgdGhhbiBwb2ludGxlc3MgbWlj cm8tb3B0bWlzYXRpb25zLgoKVGhhbmtzLApOaWNrCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51 eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5v cmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==