[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whn4DGusRgq7ihBmu7vPBhvSDZsYN_ctef94E1rVbf5jA@mail.gmail.com>
Date: Tue, 27 Jun 2023 10:56:21 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: paulmck@...nel.org, Zhu Yanjun <zyjzyj2000@...il.com>,
Jason Gunthorpe <jgg@...pe.ca>,
Leon Romanovsky <leon@...nel.org>
Cc: linux-kernel@...r.kernel.org, kernel-team@...a.com,
mingo@...nel.org, tglx@...utronix.de, rcu@...r.kernel.org
Subject: Re: [GIT PULL] RCU changes for v6.5
On Sun, 25 Jun 2023 at 08:35, Paul E. McKenney <paulmck@...nel.org> 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
Powered by blists - more mailing lists