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.7 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, 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 ED588C433DB for ; Tue, 29 Dec 2020 00:37:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C9347207FB for ; Tue, 29 Dec 2020 00:37:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729835AbgL2AhE (ORCPT ); Mon, 28 Dec 2020 19:37:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729324AbgL2AhD (ORCPT ); Mon, 28 Dec 2020 19:37:03 -0500 Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CA58C061793; Mon, 28 Dec 2020 16:36:23 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id 11so7148248pfu.4; Mon, 28 Dec 2020 16:36:23 -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=XhkB3zwKSFpfJJL95j/uWWsVgCC/SyOzuksaUOmpjVA=; b=MeyxK40WLYO0yC90yvfamYIsyRo4Xz+GSBNd+z//rnlWQ7IkSbd7O0Bz27btLYO8tg UHfFNRyUqITBFIBEQOw3phV8GdzVbpeF5jJVWWkYQDYTHTsOpOj1nUF4G5M+mRO3lOdS ucPyz9/DvHVORWimibQRBNXJfwEh8mycQFNAGFg1eoXZKR7L5wceO8fh5TikiRfCFG3T fR6Jz5QFn4I8eZhhSU2XEoPYw7LLxsE2ViAKLVQVhhMAYZ7aJu8xJiR+CZaXk1WzMiZ9 oiFEi0lr6nMTRoHTWFI/2fJzDFY84VflCUCKbK6Cr3hme9aIGSjoT2yTj7GyOpOjsghR ywMw== 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=XhkB3zwKSFpfJJL95j/uWWsVgCC/SyOzuksaUOmpjVA=; b=M1+0ff3J0DenwqkCbrw85Xq0piAG/tC5022PcId55xz6wwASQ0hMgSseMxicxZWu7e zlXHMQxKhHoJV2lPxI/FOyNxjd88aI++3bW+l6ho3MhADjvlWgQxxYPZTTgGQ3TdJTn+ ZI376YCfSVUFrHjzaxiepvqurSdrTZ5y+bJWV5qNP7+vBOSf1QrT6tqJq7Q5haPFfdMg iQo06cow5u7qTyVvPR5gy+/ab3BcneXvomthaWc7as4TbNEzLjcCWAnYeEOBtj2WVHN6 vr+McA0ijlwDB4DscpuMuOncMdFcqdt/5uyz3+SkIm/2DTJj49ie40eLYSpXNPguZPH7 64Eg== X-Gm-Message-State: AOAM531s5A7WzELnDIWFqAQQALlvg0yZk4tR5mzmj8JtmMJ5zYFM4Ra5 33eMm+6M7lubc86sh6qVTUs= X-Google-Smtp-Source: ABdhPJw/4YK0yucnDxztvfORV1tzUrP7e8hPYsw08vEhyvhWIh5qfVEa3S1Lj3OwBfDqpGkrR8pQog== X-Received: by 2002:a65:5283:: with SMTP id y3mr12944392pgp.174.1609202182882; Mon, 28 Dec 2020 16:36:22 -0800 (PST) Received: from localhost (193-116-97-30.tpgi.com.au. [193.116.97.30]) by smtp.gmail.com with ESMTPSA id i6sm30030828pgc.58.2020.12.28.16.36.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Dec 2020 16:36:22 -0800 (PST) Date: Tue, 29 Dec 2020 10:36:16 +1000 From: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Andy Lutomirski , Mathieu Desnoyers Cc: Arnd Bergmann , Benjamin Herrenschmidt , Catalin Marinas , Jann Horn , linux-arm-kernel , "Russell King, ARM Linux" , linux-kernel , linuxppc-dev , Michael Ellerman , paulmck , Paul Mackerras , Peter Zijlstra , stable , Will Deacon , x86 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: MIME-Version: 1.0 Message-Id: <1609200902.me5niwm2t6.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 Andy Lutomirski's message of December 29, 2020 7:06 am: > 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 o= f >> >> > 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 on= e >> >> > in total, but we probably don't care _that_ much about extra IPIs o= n >> >> > 32-bit arm? >> >> This was the original thinking, yes. The cacheflush IPI will flush speci= fic >> regions of code, and the membarrier IPI issues context synchronizing >> instructions. APIs should be written in terms of the service they provide to=20 userspace, and in highest level terms as possible, rather than directing=20 hardware to do some low level operation. Unfortunately we're stuck with this for now. We could deprecate it and replace it though. If userspace wants to modify code and ensure that after the system call returns then no other thread will be executing the previous code, then there should be an API for that. It could actually combine the two IPIs into one for architectures that require both too.=20 >> >> Architectures with coherent i/d caches don't need the cacheflush step. >=20 > There are different levels of coherency -- VIVT architectures may have > differing requirements compared to PIPT, etc. >=20 > 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: >=20 > 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. As said this isn't what SYNC_CORE does, and it's not what powerpc context synchronizing instructions do either, it will very much re-order visibility of stores around such an instruction. A thread completes store instructions into a store queue, which is as far as a context synchronizing event goes. Visibility comes at some indeterminite time later. Also note that the regular membarrier syscall which does order memory also does not make writes visible, it just ensures an ordering. >=20 > x86: SYNC_CORE executes a barrier that will cause subsequent > instruction fetches to observe prior writes. Currently this will be a I would be surprised if x86's serializing instructions were different=20 than powerpc. rdtsc ordering or flushing stores to cache would be surprising. Thanks, Nick > "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. >=20 > arm: Something about the cache management syscalls. >=20 > arm64: Ditto >=20 > powerpc: I have no idea. >=20 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.5 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, 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 57CCEC433E0 for ; Tue, 29 Dec 2020 00:40: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 57657207CF for ; Tue, 29 Dec 2020 00:40:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57657207CF 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 4D4bDJ0qRnzDqFs for ; Tue, 29 Dec 2020 11:40:16 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::435; helo=mail-pf1-x435.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=MeyxK40W; dkim-atps=neutral Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 4D4b7w2wLczDqD8 for ; Tue, 29 Dec 2020 11:36:26 +1100 (AEDT) Received: by mail-pf1-x435.google.com with SMTP id t22so7155161pfl.3 for ; Mon, 28 Dec 2020 16:36:25 -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=XhkB3zwKSFpfJJL95j/uWWsVgCC/SyOzuksaUOmpjVA=; b=MeyxK40WLYO0yC90yvfamYIsyRo4Xz+GSBNd+z//rnlWQ7IkSbd7O0Bz27btLYO8tg UHfFNRyUqITBFIBEQOw3phV8GdzVbpeF5jJVWWkYQDYTHTsOpOj1nUF4G5M+mRO3lOdS ucPyz9/DvHVORWimibQRBNXJfwEh8mycQFNAGFg1eoXZKR7L5wceO8fh5TikiRfCFG3T fR6Jz5QFn4I8eZhhSU2XEoPYw7LLxsE2ViAKLVQVhhMAYZ7aJu8xJiR+CZaXk1WzMiZ9 oiFEi0lr6nMTRoHTWFI/2fJzDFY84VflCUCKbK6Cr3hme9aIGSjoT2yTj7GyOpOjsghR ywMw== 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=XhkB3zwKSFpfJJL95j/uWWsVgCC/SyOzuksaUOmpjVA=; b=XURQbfTe48tySk+WnvlVqJINCtD5CKP0TYpYpxsl8v90GFaS6JrwMbq9y1kU630OBo pina22vkYSmtuZ02qJMbdw7wPd3B2XgajKBbWtAiT00wF2heXyx2MWVNQqAHY39YRMXH IbBztlK4Z/7sIfKw89P2NENbPNL9LOKJYHn09D2gqmo8hphVSMuI+qVxeea9UIUOvZ5g QT9VrBwM98tZY7lGKUOt1nHCWVw6w7I40wtKc/h/IudUN6SkoHJaV6oifx1uik8C16Oa OQu3gTRs+5BxCZ6wtMxfsvE6aHjYKkvp9ltDu++dvKTBWqBWSv4ReaWSwub8z1OfmXFi oNxA== X-Gm-Message-State: AOAM533cP7s3mxE1ZpOrqiGkU9rW7pRLUGraOMMhHd8gzNV73kMt4U1O N91rM/VZe8ovAXzLkcgc6eI= X-Google-Smtp-Source: ABdhPJw/4YK0yucnDxztvfORV1tzUrP7e8hPYsw08vEhyvhWIh5qfVEa3S1Lj3OwBfDqpGkrR8pQog== X-Received: by 2002:a65:5283:: with SMTP id y3mr12944392pgp.174.1609202182882; Mon, 28 Dec 2020 16:36:22 -0800 (PST) Received: from localhost (193-116-97-30.tpgi.com.au. [193.116.97.30]) by smtp.gmail.com with ESMTPSA id i6sm30030828pgc.58.2020.12.28.16.36.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Dec 2020 16:36:22 -0800 (PST) Date: Tue, 29 Dec 2020 10:36:16 +1000 From: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Andy Lutomirski , Mathieu Desnoyers 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: MIME-Version: 1.0 Message-Id: <1609200902.me5niwm2t6.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 , "Russell King, ARM Linux" , stable , linux-kernel , Will Deacon , Paul Mackerras , Catalin Marinas , linuxppc-dev , linux-arm-kernel Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Excerpts from Andy Lutomirski's message of December 29, 2020 7:06 am: > 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 o= f >> >> > 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 on= e >> >> > in total, but we probably don't care _that_ much about extra IPIs o= n >> >> > 32-bit arm? >> >> This was the original thinking, yes. The cacheflush IPI will flush speci= fic >> regions of code, and the membarrier IPI issues context synchronizing >> instructions. APIs should be written in terms of the service they provide to=20 userspace, and in highest level terms as possible, rather than directing=20 hardware to do some low level operation. Unfortunately we're stuck with this for now. We could deprecate it and replace it though. If userspace wants to modify code and ensure that after the system call returns then no other thread will be executing the previous code, then there should be an API for that. It could actually combine the two IPIs into one for architectures that require both too.=20 >> >> Architectures with coherent i/d caches don't need the cacheflush step. >=20 > There are different levels of coherency -- VIVT architectures may have > differing requirements compared to PIPT, etc. >=20 > 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: >=20 > 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. As said this isn't what SYNC_CORE does, and it's not what powerpc context synchronizing instructions do either, it will very much re-order visibility of stores around such an instruction. A thread completes store instructions into a store queue, which is as far as a context synchronizing event goes. Visibility comes at some indeterminite time later. Also note that the regular membarrier syscall which does order memory also does not make writes visible, it just ensures an ordering. >=20 > x86: SYNC_CORE executes a barrier that will cause subsequent > instruction fetches to observe prior writes. Currently this will be a I would be surprised if x86's serializing instructions were different=20 than powerpc. rdtsc ordering or flushing stores to cache would be surprising. Thanks, Nick > "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. >=20 > arm: Something about the cache management syscalls. >=20 > arm64: Ditto >=20 > powerpc: I have no idea. >=20 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.7 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, 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 3436EC433E6 for ; Tue, 29 Dec 2020 00:38:14 +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 D659E20719 for ; Tue, 29 Dec 2020 00:38:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D659E20719 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=m7S1xgoqJSVp1deq6EhWEAUKNqxYjcgDcgvBVkwqB18=; b=SfsjmIQW92iFYyDS6fDzQUA5E /4KHgK5z1lYs1QMmjiKD5iCPagXVJMB7zJPZp0+/b7kVzQbCtiLq6TEcc9qgFaFuPbfCkQB8b6Tle AKm3fRPows3HmRtATBBj6Vjkb5RQNiumTJKQiFiw5lljktI+q/2g3qZwSg7ZdRiX5DrnLov3tatRr QvPVeZfwdCuNFS9VFGpo4ouLByrkXAM6EtC7zMwUisUZesO3TBfPcDykAZ6TG6u9AQuj9PkVcljbr +m1jJnxPHTHGisLo10ob3oRe4yjJjwHxOkRvjBP8Vuwf1ov87CjcwTnDHPagmA25wGMMIbMm9k4bP OaT2VY77g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ku300-0008Lf-GV; Tue, 29 Dec 2020 00:36:28 +0000 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ku2zx-0008Jz-8l for linux-arm-kernel@lists.infradead.org; Tue, 29 Dec 2020 00:36:26 +0000 Received: by mail-pg1-x52e.google.com with SMTP id c22so8251830pgg.13 for ; Mon, 28 Dec 2020 16:36:24 -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=XhkB3zwKSFpfJJL95j/uWWsVgCC/SyOzuksaUOmpjVA=; b=MeyxK40WLYO0yC90yvfamYIsyRo4Xz+GSBNd+z//rnlWQ7IkSbd7O0Bz27btLYO8tg UHfFNRyUqITBFIBEQOw3phV8GdzVbpeF5jJVWWkYQDYTHTsOpOj1nUF4G5M+mRO3lOdS ucPyz9/DvHVORWimibQRBNXJfwEh8mycQFNAGFg1eoXZKR7L5wceO8fh5TikiRfCFG3T fR6Jz5QFn4I8eZhhSU2XEoPYw7LLxsE2ViAKLVQVhhMAYZ7aJu8xJiR+CZaXk1WzMiZ9 oiFEi0lr6nMTRoHTWFI/2fJzDFY84VflCUCKbK6Cr3hme9aIGSjoT2yTj7GyOpOjsghR ywMw== 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=XhkB3zwKSFpfJJL95j/uWWsVgCC/SyOzuksaUOmpjVA=; b=fJnXwgrUgk/58BLWjJYs72VZph3f4KjzGLBMSwFe4qlRfprILa1b+UdDqVOatS1HGS MUD/6KDexlTKiHd8ztES+aVuQgJRbxcUpUjAH9ce/nYCD/K2L1ozvx5oCZqY9vOMDiFR 99p92SFaVhs6lPCyYdFB7RsJEUjhIzjHaz47IKFVCMP5j48PNbgngoeGqUUVcy6SgrM1 ZdWcOsh950xFMPX4KfkfjfBHr756mADsn4vYNdw2oFNPcx7FHJ1WwknfpSIB8+tCAqx7 cikGtBU0bcGOojxWSvko4kErIkgw9hNhGelQ9rhIr5+2BvIh6oi7F6IehSOxLgs6DZKy F6kw== X-Gm-Message-State: AOAM5332WwTVeVwRpAYBRvknZii+4w4OhP09Qo0Bzb0a5p/lrl5hGC3h dl26OPtRrK6PBLg15a9yy0g= X-Google-Smtp-Source: ABdhPJw/4YK0yucnDxztvfORV1tzUrP7e8hPYsw08vEhyvhWIh5qfVEa3S1Lj3OwBfDqpGkrR8pQog== X-Received: by 2002:a65:5283:: with SMTP id y3mr12944392pgp.174.1609202182882; Mon, 28 Dec 2020 16:36:22 -0800 (PST) Received: from localhost (193-116-97-30.tpgi.com.au. [193.116.97.30]) by smtp.gmail.com with ESMTPSA id i6sm30030828pgc.58.2020.12.28.16.36.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Dec 2020 16:36:22 -0800 (PST) Date: Tue, 29 Dec 2020 10:36:16 +1000 From: Nicholas Piggin Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode() To: Andy Lutomirski , Mathieu Desnoyers 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: MIME-Version: 1.0 Message-Id: <1609200902.me5niwm2t6.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201228_193625_344021_2400EF40 X-CRM114-Status: GOOD ( 29.71 ) 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 , "Russell King, ARM Linux" , stable , linux-kernel , Will Deacon , Paul Mackerras , Michael Ellerman , Catalin Marinas , 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 Excerpts from Andy Lutomirski's message of December 29, 2020 7:06 am: > 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. APIs should be written in terms of the service they provide to userspace, and in highest level terms as possible, rather than directing hardware to do some low level operation. Unfortunately we're stuck with this for now. We could deprecate it and replace it though. If userspace wants to modify code and ensure that after the system call returns then no other thread will be executing the previous code, then there should be an API for that. It could actually combine the two IPIs into one for architectures that require both too. >> >> 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. As said this isn't what SYNC_CORE does, and it's not what powerpc context synchronizing instructions do either, it will very much re-order visibility of stores around such an instruction. A thread completes store instructions into a store queue, which is as far as a context synchronizing event goes. Visibility comes at some indeterminite time later. Also note that the regular membarrier syscall which does order memory also does not make writes visible, it just ensures an ordering. > > x86: SYNC_CORE executes a barrier that will cause subsequent > instruction fetches to observe prior writes. Currently this will be a I would be surprised if x86's serializing instructions were different than powerpc. rdtsc ordering or flushing stores to cache would be surprising. Thanks, Nick > "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