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=-11.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 70FD0C433B4 for ; Mon, 3 May 2021 03:14:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EA4E8613AA for ; Mon, 3 May 2021 03:14:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA4E8613AA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2F79A6B0036; Sun, 2 May 2021 23:14:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A7B96B006E; Sun, 2 May 2021 23:14:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 148D16B0070; Sun, 2 May 2021 23:14:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id E98BA6B0036 for ; Sun, 2 May 2021 23:14:46 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 99760180AD837 for ; Mon, 3 May 2021 03:14:46 +0000 (UTC) X-FDA: 78098452572.03.030BB3B Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf13.hostedemail.com (Postfix) with ESMTP id 72395E000111 for ; Mon, 3 May 2021 03:14:35 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 29003611CE; Mon, 3 May 2021 03:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620011685; bh=Gg6gx9+BbIJpPshU7mq6a8VhsNaJNErD+n5vwYlU4vA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=Yf3zn/i6kOoYyAerEloPaMSDXbDo61Nm3X5KgZxqodY23g7tskhuxQbZ3wqrtMTFK eldPWT70xvskkJVlLSGilTD8vG4ubg3rtztjNY9pDnh5aMQwnH+zS/dvv4VCUtzZbd kR+gi3FLCg65yjtEZ/nh6lWPDb8+9FNb0m1gC8g+3Y3shJQrLGxiS+JOXzFZ58Lt5b t/1Z8GUSNu3DKxHfyJD6CeWTvxhHFykDuk6vj1W3OmKky8SJjUna7f7Nu7g/zZCozH lRadp7HjKQnj9DFRaZaDdYbG36EQx4XaINeYd45zmM7B6Ai2cL0pzUkk7DqQEXD+qg HVbE8fHhKisVg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id E174C5C01C9; Sun, 2 May 2021 20:14:44 -0700 (PDT) Date: Sun, 2 May 2021 20:14:44 -0700 From: "Paul E. McKenney" To: Matthew Wilcox Cc: Michel Lespinasse , Andy Lutomirski , Linux-MM , Laurent Dufour , Peter Zijlstra , Michal Hocko , Rik van Riel , Andrew Morton , Suren Baghdasaryan , Joel Fernandes , Rom Lemarchand , Linux-Kernel Subject: Re: [RFC PATCH 13/37] mm: implement speculative handling in __handle_mm_fault(). Message-ID: <20210503031444.GP975577@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20210407014502.24091-1-michel@lespinasse.org> <20210407014502.24091-14-michel@lespinasse.org> <20210428145823.GA856@lespinasse.org> <20210428161108.GP975577@paulmck-ThinkPad-P17-Gen-1> <20210429000225.GC10973@lespinasse.org> <20210429155250.GV975577@paulmck-ThinkPad-P17-Gen-1> <20210429183412.GA278623@paulmck-ThinkPad-P17-Gen-1> <20210429184908.GH1847222@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210429184908.GH1847222@casper.infradead.org> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 72395E000111 X-Stat-Signature: m9tpwmt1nez6s1csdmo5fykotx9qf94w Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Yf3zn/i6"; spf=pass (imf13.hostedemail.com: domain of "SRS0=XIR6=J6=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 198.145.29.99 as permitted sender) smtp.mailfrom="SRS0=XIR6=J6=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620011675-378473 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, Apr 29, 2021 at 07:49:08PM +0100, Matthew Wilcox wrote: > On Thu, Apr 29, 2021 at 11:34:12AM -0700, Paul E. McKenney wrote: > > +++ b/include/linux/rcupdate.h > > @@ -532,7 +532,10 @@ do { \ > > * @p: The pointer to read, prior to dereferencing > > * @c: The conditions under which the dereference will take place > > * > > - * This is the RCU-bh counterpart to rcu_dereference_check(). > > + * This is the RCU-bh counterpart to rcu_dereference_check(). However, > > + * please note that in recent kernels, synchronize_rcu() waits for > > + * local_bh_disable() regions of code in addition to regions of code > > + * demarked by rcu_read_lock() and rcu_read_unlock(). > > */ > > I've been trying to get rid of "please note that" in my own documentation > recently. It doesn't add any value. Also, "recent kernels" is going to > go stale quickly, "Since v5.8" (or whatever) is good because it lets us > know in ten years that we can just delete the reference. > > So I'd make this: > > * This is the RCU-bh equivalent of rcu_dereference_check(). Since v5.8, > * synchronize_rcu() waits for code with bottom halves disabled as well > * as code between rcu_read_lock() and rcu_read_unlock(). Normally, I would be right there with you on the "less is more" approach to writing. But in this particular case: 1. I added comments to rcu_read_lock_bh(), rcu_read_lock_sched(), call_rcu(), and synchronize_rcu(). 2. I included a section entitled "RCU flavor consolidation" in the 2019 edition of the RCU API: https://lwn.net/Articles/777036/ 3. I presented on this topic at LCA: https://www.youtube.com/watch?v=hZX1aokdNiY 4. I published a paper on this topic: https://dl.acm.org/doi/10.1145/3319647.3325836 http://www.rdrop.com/~paulmck/RCU/rcu-exploit.2019.05.01a.pdf All of these, even taken together, have proven to be insufficient. This therefore does not appear to be the place to economize on words. :-/ Your point on the version (v5.0, as it turns out) is right on, and I will make that change. Thanx, Paul