Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 5 Aug 2020 16:08:52 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     kcc@google.com, dvyukov@google.com, elver@google.com
Cc:     linux-kernel@vger.kernel.org
Subject: Finally starting on short RCU grace periods, but...
Message-ID: <20200805230852.GA28727@paulmck-ThinkPad-P72>
Reply-To: paulmck@kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello!

If I remember correctly, one of you asked for a way to shorten RCU
grace periods so that KASAN would have a better chance of detecting bugs
such as pointers being leaked out of RCU read-side critical sections.
I am finally starting entering and testing code for this, but realized
that I had forgotten a couple of things:

1.	I don't remember exactly who asked, but I suspect that it was
	Kostya.  I am using his Reported-by as a placeholder for the
	moment, but please let me know if this should be adjusted.

2.	Although this work is necessary to detect situtions where
	call_rcu() is used to initiate a grace period, there already
	exists a way to make short grace periods that are initiated by
	synchronize_rcu(), namely, the rcupdate.rcu_expedited kernel
	boot parameter.  This will cause all calls to synchronize_rcu()
	to act like synchronize_rcu_expedited(), resulting in about 2-3
	orders of magnitude reduction in grace-period latency on small
	systems (say 16 CPUs).

In addition, I plan to make a few other adjustments that will
increase the probability of KASAN spotting a pointer leak even in the
rcupdate.rcu_expedited case.

But if you would like to start this sort of testing on current mainline,
rcupdate.rcu_expedited is your friend!

							Thanx, Paul