Re: [GIT PULL] RCU changes for v5.10

[Paul E. McKenney]

On Mon, Oct 12, 2020 at 01:25:09PM -0700, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 7:14 AM Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >
> > Please pull the latest core/rcu git tree from:
> >
> > RCU changes for v5.10:
> >
> >  - Debugging for smp_call_function()
> >  - RT raw/non-raw lock ordering fixes
> >  - Strict grace periods for KASAN
> >  - New smp_call_function() torture test
> >  - Torture-test updates
> >  - Documentation updates
> >  - Miscellaneous fixes
> 
> I am *very* unhappy with this pull request.
> 
> It doesn't even mention the big removal of CONFIR_PREEMPT, that I felt
> was still under discussion.
> 
> I don't absolutely hate that code, and I'm willing to be convinced
> about how little it matter for people who don't want to have the
> counting overhead, but I refuse to pull it as some secret hidden thing
> that isn't even mentioned in the pull request.
> 
> Honestly, I did not get any strong arguments for why making the
> preempt count unconditional was such an important thing.
> 
> Yes, Thomas pointed me at a couple of uses that were garbage, but even
> the people involved in those seemed to agree they were legacy garbage.
> 
> So why was this preempt-count thing then pushed through like this?

So that RCU can tell, even in CONFIG_PREEMPT_NONE=y kernels, whether it
is safe to invoke the memory allocator.  RCU needs to figure this out
for -rt kernels and for the CONFIG_PROVE_RAW_LOCK_NESTING Kconfig option
that was recently added to lockdep.  And with this option, lockdep has
been triggering for kvfree_rcu() for awhile now.

We have tried a number of alternative fixes, but they have had subtle
problems.  Or, in the case of the alternative that uses a lockless
interface to the memory allocator, the not-so-subtle problem of strong
resistance from the maintainers.

In contrast, your earlier comments seemed to indicate that with a valid
use case, you would be OK with unconditional PREEMPT_COUNT, though
perhaps that was a case of excessive optimism on my part.  I based my
optimism in part on your not having complained about either the patch
series or the pull request, both of which I CCed you on:

https://lore.kernel.org/lkml/20200928233041.GA23230@paulmck-ThinkPad-P72
	Patch series.

https://lore.kernel.org/lkml/20201001210750.GA25287@paulmck-ThinkPad-P72
	Pull request.

Of course, if you hate this approach, we can go back to browbeating the
memory-allocator maintainers.  On the other hand, the approach used in
this pull request does work quite well and I do know that there are
people who were quite tired of the kvfree_rcu() lockdep complaints
starting quite some time ago.

But either way, please let me know how you would like us to proceed.

							Thanx, Paul