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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94EC8C04A6A for ; Thu, 27 Jul 2023 16:09:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3E1E6B0071; Thu, 27 Jul 2023 12:09:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEDF36B0074; Thu, 27 Jul 2023 12:09:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B6446B0075; Thu, 27 Jul 2023 12:09:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 87F076B0071 for ; Thu, 27 Jul 2023 12:09:20 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0FF7112103A for ; Thu, 27 Jul 2023 16:09:19 +0000 (UTC) X-FDA: 81057876480.20.DB68694 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 0E41FC001B for ; Thu, 27 Jul 2023 16:09:17 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=So6i3veC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of "SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690474158; a=rsa-sha256; cv=none; b=vWGBFvEDk3Pj1SlZErT3eU3z5AgkKRMgfFirqRFZq5Q0hxv+k3CjQM96jcg/8GCGIbdBEJ umtjhuUkSV4G62UiJAouBni4b45n3kk4T+S8nzvr7nU1pjVtY5PgWSE/Ay2wpXj/F4SUcR YPdBZegDZsjmwRrMtJGImAPApGkGUhc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=So6i3veC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of "SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=+Ard=DN=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690474158; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FoZdCe+lo3DsmtoIEQ5O7+n95dutVY5n8blVnhO+zQw=; b=Sg289h76lL6I7Q7kaZ+5Svc4/dzfiDkckahSRWyCJmr5tbp7I5VX0cKOVP0fpsL/7l1f1X O1PMS1Wvlpg/shn7seipPl0DwiSrfn1c54Fvx37bFA5Q4vX8nZNGx8Vo7p5ldNR2sXDLoJ i87+RaEuFU/SC7S6ZnETXi6OSa5wAI4= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CD06161EBD; Thu, 27 Jul 2023 16:09:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F2FEC433C8; Thu, 27 Jul 2023 16:09:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690474156; bh=OVB2HnBwuq4s+VFd9Hwc8Ai7TvaLJTTKhvDjcGcBCwM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=So6i3veCC5QVdy8A6oURdQYjr2v7mOmlfPLsEFCsoQ+g+rcWYGNJEXfacqYLAgcCw uyj6HfjjfHmLZjIjFqtFgS/tvhlnH7XZ35691KfR9ds0/9ubZlZtdnmdw8kRhm3R23 4dBKNKdGc9EKI/hp6T9fyCxm7aNIrxVG0/ynWsootj8hqxHYBx5CXnsNc6YkZUO0jq Da0N4CW4Gomi7rNvPKdIegGrSp0LSCSxdUyQQfnsMgTKiXcTJHvp7knMLT45uBNxx8 766HRIrBsOC1W2zHHYa23ZtiR5RPreA9oSpLQPThaHrWznHpl+5dXcS4RK8yYEV/D6 xtXc/8m+2iF8g== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id B2249CE0B66; Thu, 27 Jul 2023 09:09:15 -0700 (PDT) Date: Thu, 27 Jul 2023 09:09:15 -0700 From: "Paul E. McKenney" To: Matthew Wilcox Cc: Jann Horn , Andrew Morton , Linus Torvalds , Peter Zijlstra , Suren Baghdasaryan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alan Stern , Andrea Parri , Will Deacon , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Joel Fernandes Subject: Re: [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering Message-ID: <01bcf3aa-6072-45e6-9149-c2cd99171454@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20230726214103.3261108-1-jannh@google.com> <31df93bd-4862-432c-8135-5595ffd2bd43@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0E41FC001B X-Stat-Signature: egjaybz1gpuayqz54suygr9r91ddf53c X-HE-Tag: 1690474157-946271 X-HE-Meta: U2FsdGVkX19hruM6Y8IaF3LR3pfNQKLOLA4VNO7kSe6gpsUyG6deJVYpyY0GIZkO6bcBuI86TrDne0clBLmXmxD/we/4D/wCht844ExYAWclmHa3TGrQy3jjA+Cyuh5feelkFy27s9D0AAaEYs/xGMGHZO7u5W4mIVsTEfKGQXuJpyZGStUnuouAe+g0D5wfZqCWlQ8RzXWfOvE1FhnyXf+6RSL1rxeX/mZeJtTY8c1koL/WqjFqgln/BGyT/5/qvXTqSdkaeRm4xh8VkPAlcrm5FTGEEoGbk+EkfBt6IAfLV3bgRJNomrJ4SWH+6SAL1X5yyDCzpC6XZ5CuexlYJcGBXeWOx7C7vTJT4cIisnyqHuMSEh3v/xtNehw+iThe3Kwq4U2lnbhy1lH00gLEaVWE2ExhihnTx8I95KuOm/7QB4TdLp/xs0PFfFuSL1v/TyHnbTXK5+7vLqJMF9jlzcj/xV5G5OS7iKoPxW1v9/gtO7mXHfy9Uo1sP9e5FsqjurSWCjY74iA1Bbu6KM6jT7z4adW36l3sK/kOXTwAuRQbJEv77CE1iHWqGl3EckYR9TE6xFrRFovPTkdUgu946wDoOyciA7dyYdZLM+3DFZtDEHPtaktojvR68NHLRKmSN81wyMJJpq7GhUDJK9DZu+nguzsKdK1A+rYeygUKfj8aTZxLefszuWxCQ4jMA1RNaT1MxqYOjcaYGsYrJ/XhbmWIOl9BtEzTsCjWWXbABuzN3dprZVTSpJ6gXAUCyCqR1u206wa0OOu97LTNISdNrVG0p9OUsRP70NsIWyssgMLRlG7GrkXbQnFPRc2AOp9sQK2Xg5zfy2B8wz6Kq0zmVxYgxnv+35q2zPZy9o268RMMvUREltLnXmCsz9RuQCjGH7KyaYBINcyxh+y+j7yH7VodWT8dH9A1o8NLdFJbPvd1Mr6sZUu37Mdao7qPFJXGB6+ixmzPSOMJDyWfpBW fiF/Xf7r V7H2MEFCWOHirW/6oH2ECmDoPgLEFrcO1pbBi0jGTl9hyXo7ez0aKxL7MXBz4Tl1uzjfml1qXleggBnG2YRDGH8/AofPQGnrXE66hUWjL2HZM+yDsBI8Noar7Dv/GgsoLiKC7T914/d3Oxkdf/4H5mTdfG0CfGnx4MFfd9YAQ0WrlIrLxqlJiKRUIVy5TcTQdW2EHtUZcBiYaUWosR+7xw9yEQqNg54/UK8WzNNv5qbSsvdSOnQ3Fl4sMmahCTU+ThkfDpup+pvdRIcMU6PAj4hkQbYJejcGooGNcDzN3kStcvqfyOFodAxraRD+P9byj5EabtSKW4xWYzjSYfxYvBtpz13T3anG8njkTQGKJWpwsxRRvYV3COD1lobxvd4MUXpNwwGu03VVrU869Bsza+G9v8S7UhVbUzZtZe/LJQEOKNayx6pVcxBY71JL9v+y1DeUctzyYkitbkj8LfhIlKsztCCbkCRd3k3RHUG7wt4X1LzYT4VMl0CdJjnzhGYJHtKav7RikF5tqYxFc2MVvVTBDE0npc/v3ouUv2whgCf2X2OOy77+0VIqC2OWkqVNbcrgyYdYbSCyY7nGdREdRCa5xqxQwq7WzH6MSiOzrxsdmVAka8uUQD6VB3z6RpWzDsCP/RG+Z0sIchNjYRIsRqisuP+wjlo0hiYtFmoedUaKQ11mZRLUvRiboBFpcjjeMY+ljd8Yu6+oBXXcZD3ffgbfzwM1WITOkKPEt X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 27, 2023 at 04:07:32PM +0100, Matthew Wilcox wrote: > On Thu, Jul 27, 2023 at 04:39:34PM +0200, Jann Horn wrote: > > Assume that we are holding some kind of lock that ensures that the > > only possible concurrent update to "vma->anon_vma" is that it changes > > from a NULL pointer to a non-NULL pointer (using smp_store_release()). > > > > > > if (READ_ONCE(vma->anon_vma) != NULL) { > > // we now know that vma->anon_vma cannot change anymore > > > > // access the same memory location again with a plain load > > struct anon_vma *a = vma->anon_vma; > > > > // this needs to be address-dependency-ordered against one of > > // the loads from vma->anon_vma > > struct anon_vma *root = a->root; > > } > > > > > > Is this fine? If it is not fine just because the compiler might > > reorder the plain load of vma->anon_vma before the READ_ONCE() load, > > would it be fine after adding a barrier() directly after the > > READ_ONCE()? > > > > I initially suggested using READ_ONCE() for this, and then Linus and > > me tried to reason it out and Linus suggested (if I understood him > > correctly) that you could make the ugly argument that this works > > because loads from the same location will not be reordered by the > > hardware. So on anything other than alpha, we'd still have the > > required address-dependency ordering because that happens for all > > loads, even plain loads, while on alpha, the READ_ONCE() includes a > > memory barrier. But that argument is weirdly reliant on > > architecture-specific implementation details. > > > > The other option is to replace the READ_ONCE() with a > > smp_load_acquire(), at which point it becomes a lot simpler to show > > that the code is correct. > > Aren't we straining at gnats here? The context of this is handling a > page fault, and we used to take an entire rwsem for read. I'm having > a hard time caring about "the extra expense" of an unnecessarily broad > barrier. > > Cost of an L3 cacheline miss is in the thousands of cycles. Cost of a > barrier is ... tens? Couldn't agree more! Thanx, Paul