Hello, Linus,
Once the merge window opens, please pull the latest RCU git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/rcu.2023.06.22a
# HEAD: 2e31da752c6d0e892f2a9232e18da816d04ee691: Merge branches 'doc.2023.05.10a', 'fixes.2023.05.11a', 'kvfree.2023.05.10a', 'nocb.2023.05.11a', 'rcu-tasks.2023.05.10a', 'torture.2023.05.15a' and 'rcu-urgent.2023.06.06a' into HEAD (2023-06-07 13:44:06 -0700)
----------------------------------------------------------------
RCU pull request for v6.5
This pull contains the following branches:
doc.2023.05.10a: Documentation updates
fixes.2023.05.11a: Miscellaneous fixes, perhaps most notably:
o Remove RCU_NONIDLE(). The new visibility of most of the idle
loop to RCU has obsoleted this API.
o Make the RCU_SOFTIRQ callback-invocation time limit also apply
to the rcuc kthreads that invoke callbacks for CONFIG_PREEMPT_RT.
o Add a jiffies-based callback-invocation time limit to handle
long-running callbacks. (The local_clock() function is only
invoked once per 32 callbacks due to its high overhead.)
o Stop rcu_tasks_invoke_cbs() from using never-onlined CPUs,
which fixes a bug that can occur on systems with non-contiguous
CPU numbering.
kvfree.2023.05.10a: kvfree_rcu updates
o Eliminate the single-argument variant of k[v]free_rcu() now
that all uses have been converted to k[v]free_rcu_mightsleep().
o Add WARN_ON_ONCE() checks for k[v]free_rcu*() freeing callbacks
too soon. Yes, this is closing the barn door after the horse
has escaped, but Murphy says that there will be more horses.
nocb.2023.05.11a: Callback-offloading updates
o Fix a number of bugs involving the shrinker and lazy callbacks.
rcu-tasks.2023.05.10a: Tasks RCU updates
torture.2023.05.15a: Torture-test updates
rcu-urgent.2023.06.06a: Urgent SRCU fix (already pulled)
----------------------------------------------------------------
Chen-Yu Tsai (1):
notifier: Initialize new struct srcu_usage field
Frederic Weisbecker (4):
rcu/nocb: Protect lazy shrinker against concurrent (de-)offloading
rcu/nocb: Fix shrinker race against callback enqueuer
rcu/nocb: Recheck lazy callbacks under the ->nocb_lock from shrinker
rcu/nocb: Make shrinker iterate only over NOCB CPUs
Paul E. McKenney (14):
doc: Get rcutree module parameters back into alpha order
doc: Document the rcutree.rcu_resched_ns module parameter
srcu: Remove extraneous parentheses from srcu_read_lock() etc.
rcu/kvfree: Add debug to check grace periods
rcu: Add more RCU files to kernel-api.rst
rcu: Check callback-invocation time limit for rcuc kthreads
rcu: Employ jiffies-based backstop to callback time limit
rcu: Mark additional concurrent load from ->cpu_no_qs.b.exp
rcu: Mark rcu_cpu_kthread() accesses to ->rcu_cpu_has_work
rcu: Make rcu_cpu_starting() rely on interrupts being disabled
rcu-tasks: Stop rcu_tasks_invoke_cbs() from using never-onlined CPUs
locktorture: Add long_hold to adjust lock-hold delays
rcutorture: Correct name of use_softirq module parameter
Merge branches 'doc.2023.05.10a', 'fixes.2023.05.11a', 'kvfree.2023.05.10a', 'nocb.2023.05.11a', 'rcu-tasks.2023.05.10a', 'torture.2023.05.15a' and 'rcu-urgent.2023.06.06a' into HEAD
Peter Zijlstra (1):
rcu: Remove RCU_NONIDLE()
Qiuxu Zhuo (2):
rcu/rcuscale: Move rcu_scale_*() after kfree_scale_cleanup()
rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale
Shigeru Yoshida (1):
rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()
Uladzislau Rezki (Sony) (3):
rcu/kvfree: Eliminate k[v]free_rcu() single argument macro
rcu/kvfree: Add debug check for GP complete for kfree_rcu_cpu list
rcu/kvfree: Do not run a page work if a cache is disabled
Zhouyi Zhou (1):
torture: Remove duplicated argument -enable-kvm for ppc64
Zqiang (7):
MAINTAINERS: Update [email protected] to [email protected]
rcu/kvfree: Invoke debug_rcu_bhead_unqueue() after checking bnode->gp_snap
rcu/kvfree: Use consistent krcp when growing kfree_rcu() page cache
rcu/kvfree: Make fill page cache start from krcp->nr_bkv_objs
rcu/kvfree: Make drain_page_cache() take early return if cache is disabled
rcu-tasks: Clarify the cblist_init_generic() function's pr_info() output
doc/rcutorture: Add description of rcutorture.stall_cpu_block
.../RCU/Design/Requirements/Requirements.rst | 36 +---
Documentation/RCU/whatisRCU.rst | 1 -
Documentation/admin-guide/kernel-parameters.txt | 140 ++++++++-------
Documentation/core-api/kernel-api.rst | 12 ++
MAINTAINERS | 2 +-
include/linux/notifier.h | 10 ++
include/linux/rcupdate.h | 54 +-----
include/linux/srcu.h | 8 +-
kernel/locking/locktorture.c | 51 +++---
kernel/rcu/Kconfig | 18 ++
kernel/rcu/rcu.h | 6 +
kernel/rcu/rcuscale.c | 199 +++++++++++----------
kernel/rcu/tasks.h | 12 +-
kernel/rcu/tree.c | 131 +++++++++-----
kernel/rcu/tree_exp.h | 2 +-
kernel/rcu/tree_nocb.h | 52 +++++-
kernel/rcu/tree_plugin.h | 4 +-
.../testing/selftests/rcutorture/bin/functions.sh | 2 +-
.../rcutorture/configs/rcu/BUSTED-BOOST.boot | 2 +-
.../selftests/rcutorture/configs/rcu/TREE03.boot | 2 +-
20 files changed, 412 insertions(+), 332 deletions(-)
On Sun, 25 Jun 2023 at 08:35, Paul E. McKenney <[email protected]> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/rcu.2023.06.22a
>
> o Eliminate the single-argument variant of k[v]free_rcu() now
> that all uses have been converted to k[v]free_rcu_mightsleep().
Well, clearly not all users had been.
The base of this RCU was v6.4-rc1, and when that commit was done, we
still had a single-argument variant:
7e3f926bf453 ("rcu/kvfree: Eliminate k[v]free_rcu() single argument macro")
but look here:
git grep 'kfree_rcu([^,()][^,()]*)' 7e3f926bf453
results in
7e3f926bf453:drivers/infiniband/sw/rxe/rxe_verbs.c: kfree_rcu(mr);
so the RCU tree itself can not possibly have built cleanly.
How the heck did this pass testing in linux-next? Did linux-next just
assume that it was a merge error, and fix it up?
Anyway, I *did* fix it up, changing the 'kfree_rcu()' to
'kfree_rcu_mightsleep()', but no, this was not a merge artifact. This
was purely "the RCU tree did not build on its own", and as a result
the tree does not bisect cleanly if you have rdma enabled.
Adding rdma people to the participants just to let them know that this
happened, but it's not their fault. This is on the RCU tree, and lack
of proper coverage testing.
Linus
The pull request you sent on Sun, 25 Jun 2023 08:35:40 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/rcu.2023.06.22a
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/af96134dc8562f9fcbb8358af36f6086619a29ab
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Tue, Jun 27, 2023 at 10:56:21AM -0700, Linus Torvalds wrote:
> On Sun, 25 Jun 2023 at 08:35, Paul E. McKenney <[email protected]> wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/rcu.2023.06.22a
> >
> > o Eliminate the single-argument variant of k[v]free_rcu() now
> > that all uses have been converted to k[v]free_rcu_mightsleep().
>
> Well, clearly not all users had been.
>
> The base of this RCU was v6.4-rc1, and when that commit was done, we
> still had a single-argument variant:
>
> 7e3f926bf453 ("rcu/kvfree: Eliminate k[v]free_rcu() single argument macro")
>
> but look here:
>
> git grep 'kfree_rcu([^,()][^,()]*)' 7e3f926bf453
>
> results in
>
> 7e3f926bf453:drivers/infiniband/sw/rxe/rxe_verbs.c: kfree_rcu(mr);
>
> so the RCU tree itself can not possibly have built cleanly.
>
> How the heck did this pass testing in linux-next? Did linux-next just
> assume that it was a merge error, and fix it up?
Because idiot here failed to notice that the needed change was only
in -next, and not yet in mainline.
What I needed to have done instead was to keep this commit in -next,
but not send it to mainline until the v6.6 merge window. Or maybe to
send it as a separate pull request once the rdma commit hit mainline.
> Anyway, I *did* fix it up, changing the 'kfree_rcu()' to
> 'kfree_rcu_mightsleep()', but no, this was not a merge artifact. This
> was purely "the RCU tree did not build on its own", and as a result
> the tree does not bisect cleanly if you have rdma enabled.
>
> Adding rdma people to the participants just to let them know that this
> happened, but it's not their fault. This is on the RCU tree, and lack
> of proper coverage testing.
Apologies to all for my confusion, and thank you Linus for cleaning up
my mess!
Thanx, Paul
On Tue, Jun 27, 2023 at 11:30:46AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 27, 2023 at 10:56:21AM -0700, Linus Torvalds wrote:
> > On Sun, 25 Jun 2023 at 08:35, Paul E. McKenney <[email protected]> wrote:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/rcu.2023.06.22a
> > >
> > > o Eliminate the single-argument variant of k[v]free_rcu() now
> > > that all uses have been converted to k[v]free_rcu_mightsleep().
> >
> > Well, clearly not all users had been.
> >
> > The base of this RCU was v6.4-rc1, and when that commit was done, we
> > still had a single-argument variant:
> >
> > 7e3f926bf453 ("rcu/kvfree: Eliminate k[v]free_rcu() single argument macro")
> >
> > but look here:
> >
> > git grep 'kfree_rcu([^,()][^,()]*)' 7e3f926bf453
> >
> > results in
> >
> > 7e3f926bf453:drivers/infiniband/sw/rxe/rxe_verbs.c: kfree_rcu(mr);
> >
> > so the RCU tree itself can not possibly have built cleanly.
> >
> > How the heck did this pass testing in linux-next? Did linux-next just
> > assume that it was a merge error, and fix it up?
>
> Because idiot here failed to notice that the needed change was only
> in -next, and not yet in mainline.
It passed testing in linux-next because Stephen fixes eveything so it compiles:
https://lore.kernel.org/all/[email protected]/
It seems Stephen's report is a bit odd because it wasn't a merge issue
vs rdma, it was vs v6.4-rc1..
I suppose the question is why didn't something like Intel 0-day catch
it when it trial compiled the RCU tree's branch.
BTW, Stephen's merge is different than yours, his is based on Bob's
note here:
https://lore.kernel.org/linux-rdma/[email protected]/
I'll fix it in the next cycle.
Thanks,
Jason
On Wed, Jun 28, 2023 at 10:34:34AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 27, 2023 at 11:30:46AM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 27, 2023 at 10:56:21AM -0700, Linus Torvalds wrote:
> > > On Sun, 25 Jun 2023 at 08:35, Paul E. McKenney <[email protected]> wrote:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/rcu.2023.06.22a
> > > >
> > > > o Eliminate the single-argument variant of k[v]free_rcu() now
> > > > that all uses have been converted to k[v]free_rcu_mightsleep().
> > >
> > > Well, clearly not all users had been.
> > >
> > > The base of this RCU was v6.4-rc1, and when that commit was done, we
> > > still had a single-argument variant:
> > >
> > > 7e3f926bf453 ("rcu/kvfree: Eliminate k[v]free_rcu() single argument macro")
> > >
> > > but look here:
> > >
> > > git grep 'kfree_rcu([^,()][^,()]*)' 7e3f926bf453
> > >
> > > results in
> > >
> > > 7e3f926bf453:drivers/infiniband/sw/rxe/rxe_verbs.c: kfree_rcu(mr);
> > >
> > > so the RCU tree itself can not possibly have built cleanly.
> > >
> > > How the heck did this pass testing in linux-next? Did linux-next just
> > > assume that it was a merge error, and fix it up?
> >
> > Because idiot here failed to notice that the needed change was only
> > in -next, and not yet in mainline.
>
> It passed testing in linux-next because Stephen fixes eveything so it compiles:
>
> https://lore.kernel.org/all/[email protected]/
>
> It seems Stephen's report is a bit odd because it wasn't a merge issue
> vs rdma, it was vs v6.4-rc1..
>
> I suppose the question is why didn't something like Intel 0-day catch
> it when it trial compiled the RCU tree's branch.
The revert meant that 0-day didn't see -rcu without the single-argument
kfree_rcu() definition.
Thanx, Paul
On Wed, Jun 28, 2023 at 06:46:50AM -0700, Paul E. McKenney wrote:
> The revert meant that 0-day didn't see -rcu without the single-argument
> kfree_rcu() definition.
0-day is also supposed to run on your branches, not just linux-next,
at least it does for my trees..
Jason
On Wed, Jun 28, 2023 at 11:00:50AM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 28, 2023 at 06:46:50AM -0700, Paul E. McKenney wrote:
>
> > The revert meant that 0-day didn't see -rcu without the single-argument
> > kfree_rcu() definition.
>
> 0-day is also supposed to run on your branches, not just linux-next,
> at least it does for my trees..
It did complain back in February, but for whatever reason has not
complained about the lack fo single-argumen kfree_rcu() since then.
Thanx, Paul