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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 949FAC2B9F4 for ; Thu, 17 Jun 2021 15:18:51 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 56614613A9 for ; Thu, 17 Jun 2021 15:18:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56614613A9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=efficios.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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Subject:References: In-Reply-To:Message-ID:Cc:To:From:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=c7pafwwkXDrFWm4u/xrLP5SW7SI7gvuIT3DBzj+KhG8=; b=mV8lBNeqczOaVMeYt912bP4HWr EVnoNeUyXjadjHl6h+2H8+a9whR52kmw0Ym0eQSRtWOydqUxvTXqkOBIPedjtjAU74GBg2eUD0QY6 rI1MbXe4f9rYDLywpHOOOJFn0py+1WLg0fmshgEkIFx8Rrjw1m2XEkDnBI9Wb2wDtZrUceN8zWmIH 2SlVpY2hUBMgcmapzxPWv8urgJri/WeAax1zOVDwznhUA20pJz5Z/gFUynMeWY7lMtd/215Gyp2ON 11g8FJjjpwPtXuXgXeEZ1A5MHGgo/yshd6C4503hwwJxvkX8LFFsOjEWI21KBaoF1+p1qecNM1nCt 2r89uEFA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lttlN-00Ati8-Bw; Thu, 17 Jun 2021 15:17:01 +0000 Received: from mail.efficios.com ([167.114.26.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lttlJ-00Atgf-NO for linux-arm-kernel@lists.infradead.org; Thu, 17 Jun 2021 15:16:59 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 6DF8E33B97A; Thu, 17 Jun 2021 11:16:55 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6FkT1ZEic_fK; Thu, 17 Jun 2021 11:16:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id EB82733BC58; Thu, 17 Jun 2021 11:16:54 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com EB82733BC58 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1623943015; bh=ROnVRWF2UoAH/7ueXDWMtiXvYVP3M18VQ9wYPKu2gEw=; h=Date:From:To:Message-ID:MIME-Version; b=P3k3qk1cnD1lMMto5ySMR/WelzJExEJ0HujojzWruRzISCZGhhmX+ioxDmw7PyeGY oc4J928o7tDQSr8QG5gctcQsXN95YjffhsNb9fhoO0kXBhAvobKcaHCgIib33jUV+A QKL5TS9POshsmjI/cnxrpblCA4P/44fRil8k7b6Ja0WyqHiWxpJ4V0X0LEaFPmg8KR p1uHtTQkVc9VtTun/4yDAmZleAPe774yTA0HkLdpI43TB2+hP1JNLsW9QJmdbxhCn5 4D5uifFDlPd8EneKXQyeSyBkA/Wv0cBWm6/WXKIw94lkdgdBaK5T7k+t35CT+TGlE8 YeRPeMiEqjrPA== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cG6XBCwS7rhr; Thu, 17 Jun 2021 11:16:54 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id D62BE33BD1F; Thu, 17 Jun 2021 11:16:54 -0400 (EDT) Date: Thu, 17 Jun 2021 11:16:54 -0400 (EDT) From: Mathieu Desnoyers To: Andy Lutomirski Cc: x86 , Dave Hansen , linux-kernel , linux-mm , Andrew Morton , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , Nicholas Piggin , Catalin Marinas , Will Deacon , linux-arm-kernel , Peter Zijlstra , stable Message-ID: <1939350496.10696.1623943014767.JavaMail.zimbra@efficios.com> In-Reply-To: <07a8b963002cb955b7516e61bad19514a3acaa82.1623813516.git.luto@kernel.org> References: <07a8b963002cb955b7516e61bad19514a3acaa82.1623813516.git.luto@kernel.org> Subject: Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation MIME-Version: 1.0 X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4018 (ZimbraWebClient - FF89 (Linux)/8.8.15_GA_4026) Thread-Topic: membarrier: Rewrite sync_core_before_usermode() and improve documentation Thread-Index: ELJGNmQxqiwrOsT5GguO2Vz+nt4HDg== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210617_081657_899768_09B2FB12 X-CRM114-Status: GOOD ( 15.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Jun 15, 2021, at 11:21 PM, Andy Lutomirski luto@kernel.org wrote: [...] > +# An architecture that wants to support > +# MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE needs to define precisely what it > +# is supposed to do and implement membarrier_sync_core_before_usermode() to > +# make it do that. Then it can select ARCH_HAS_MEMBARRIER_SYNC_CORE via > +# Kconfig.Unfortunately, MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE is not a > +# fantastic API and may not make sense on all architectures. Once an > +# architecture meets these requirements, Can we please remove the editorial comment about the quality of the membarrier sync-core's API ? At least it's better than having all userspace rely on mprotect() undocumented side-effects to perform something which typically works, until it won't, or until this prevents mprotect's implementation to be improved because it will start breaking JITs all over the place. We can simply state that the definition of what membarrier sync-core does is defined per-architecture, and document the sequence of operations to perform when doing cross-modifying code specifically for each architecture. Now if there are weird architectures where membarrier is an odd fit (I've heard that riscv might need address ranges to which the core sync needs to apply), then those might need to implement their own arch-specific system call, which is all fine. > +# > +# On x86, a program can safely modify code, issue > +# MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, and then execute that code, via > +# the modified address or an alias, from any thread in the calling process. > +# > +# On arm64, a program can modify code, flush the icache as needed, and issue > +# MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE to force a "context synchronizing > +# event", aka pipeline flush on all CPUs that might run the calling process. > +# Then the program can execute the modified code as long as it is executed > +# from an address consistent with the icache flush and the CPU's cache type. > +# > +# On powerpc, a program can use MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE > +# similarly to arm64. It would be nice if the powerpc maintainers could > +# add a more clear explanantion. We should document the requirements on ARMv7 as well. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel