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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 BF00EC4361B for ; Sat, 19 Dec 2020 12:45:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8658F23443 for ; Sat, 19 Dec 2020 12:45:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726625AbgLSMpk (ORCPT ); Sat, 19 Dec 2020 07:45:40 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:41995 "EHLO wout1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726479AbgLSMpg (ORCPT ); Sat, 19 Dec 2020 07:45:36 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B49305BC; Sat, 19 Dec 2020 07:44:49 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 19 Dec 2020 07:44:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=NrxrFEeftK5SEyWxieqEkdybKx2 8bAmQY0MRbiwbMrY=; b=cFUFCQuQh6rJ6EYk0GPqTE8o2K0PkW/H2PjkJAE0ZtI oI7WHJrCAmY71ixOSPouA52v6pbAB46ZiDO24LcWPRGACj14J/I2Pj7UH+D1zMqB dWsm1zblhb+Jwe4G0NE8+Oh+AeSWz/qEH/9er7ZX77E+FqdtMDMamri2ZEgdvBfm XNjawNMwKXoRVUltE9qjFBMzRA24j+jXLPfu7EsrkKmXJ7u8nP7FEaepe5XeBqKS loAoGQFzzpeSmd1Q2mACDAoBuccFioO2CR/KpGKozIyylct8zFpwe58j49Y3de2K xwA8xe/mdlIKXnzaQWDYWpLFS3fKxKEarqYj7shz5uw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=NrxrFE eftK5SEyWxieqEkdybKx28bAmQY0MRbiwbMrY=; b=FynPPEvLKSnXLn9RTHWjKh ao3DhwqJQ+okSzLPhZOE/L6fq26b2XoH1OIezezFXtSiQDMMcRr0+mIITeXox4Cr V+nZrA97yLHikfbZ8LBIDPgnNEL0BNAUV3+OEgmbw/pyLj2HWJ+j7qbre5grfTVN dV2XCqCM4hwjqhgcgDhNDtVDSXlofPzIFLmIxXAzmJucLBWFUGcWPbYpuQgAl7K1 6OHwhk95+gKMYjQ2kUQG2n/WXQLYXhsdYKU+oY/uP1z3lrUauN3knsvSwxmCSAHL Pi4SSJtOLihU2NdXCT0JiYoD6z7bD1DmuLNrPHR6PtVRVpUQp8CaZOaQnJe4+Obg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelkedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgvghcu mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeeuleeltd ehkeeltefhleduuddvhfffuedvffduveegheekgeeiffevheegfeetgfenucffohhmrghi nhepkhgvrhhnvghlrdhorhhgnecukfhppeekfedrkeeirdejgedrieegnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghh rdgtohhm X-ME-Proxy: Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) by mail.messagingengine.com (Postfix) with ESMTPA id 6AA021080059; Sat, 19 Dec 2020 07:44:47 -0500 (EST) Date: Sat, 19 Dec 2020 13:46:08 +0100 From: Greg KH To: Andy Lutomirski Cc: x86@kernel.org, Mathieu Desnoyers , LKML , Nicholas Piggin , Arnd Bergmann , Anton Blanchard , Thomas Gleixner , stable@vger.kernel.org Subject: Re: [PATCH backport] membarrier: Explicitly sync remote cores when SYNC_CORE is requested Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 14, 2020 at 10:00:43AM -0800, Andy Lutomirski wrote: > commit 758c9373d84168dc7d039cf85a0e920046b17b41 upstream > > membarrier() does not explicitly sync_core() remote CPUs; instead, it > relies on the assumption that an IPI will result in a core sync. On x86, > this may be true in practice, but it's not architecturally reliable. In > particular, the SDM and APM do not appear to guarantee that interrupt > delivery is serializing. While IRET does serialize, IPI return can > schedule, thereby switching to another task in the same mm that was > sleeping in a syscall. The new task could then SYSRET back to usermode > without ever executing IRET. > > Make this more robust by explicitly calling sync_core_before_usermode() > on remote cores. (This also helps people who search the kernel tree for > instances of sync_core() and sync_core_before_usermode() -- one might be > surprised that the core membarrier code doesn't currently show up in a > such a search.) > > Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") > Signed-off-by: Andy Lutomirski > Signed-off-by: Thomas Gleixner > Reviewed-by: Mathieu Desnoyers > Cc: stable@vger.kernel.org > Link: https://lore.kernel.org/r/776b448d5f7bd6b12690707f5ed67bcda7f1d427.1607058304.git.luto@kernel.org > --- > > My stable membarrier series depends on commit 2a36ab717e8f > ("rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ"). I don't > think it makes much sense to backport that feature, so here's a backport of > the patch that doesn't need it. Now queued up to 5.4.y and 5.9.y, thanks. greg k-h