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

[Linus Torvalds]

On Mon, Oct 12, 2020 at 4:54 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
>
> In CONFIG_PREEMPT_NONE=y kernels, RCU has no way to tell whether or
> not its caller holds a raw spinlock, which some callers do.

Only kfree_rcu()? (And apparently eventually call_rcu())?

And since we have lockdep, and it warns about it, and raw spinlocks
are really really rare, do we really need to then disable this simple
optimization for everybody else?

We have been very successful with "don't do that then" rules.

Eg, you cannot do normal memory allocations inside a spinlock (or you
have to mark them with GFP_ATOMIC, and not all allocations can be
marked as such), and this has been the case basically forever. And we
have debug code and tools that will check that.

Why is it impossible to just say "you can't do kfree_rcu() while
holding a raw spinlock"?

Particularly for something like kfree_rcu() and particularly if it's
just about raw spinlocks, it would seem to be very natural to just say
"just delay freeing it until after you've released the raw spinlock".

Because I sure hope that you don't find raw spinlock users in random
places. It should be stuff like core scheduling, RCU itself, etc.

> Making CONFIG_PREEMPT_COUNT unconditional allows
> RCU to make this determination.

I understand _that_ part, but the thing I find objectionable is how a
small piece of code seems to want to change the rules we have had in
the kernel since basically day #1.

(Ok, so the preempt count itself is much more recent than "day #1",
but the basic non-counting spinlocks do go back to very early in the
SMP stages).

                    Linus