On Mon, Oct 12, 2020 at 01:25:09PM -0700, Linus Torvalds wrote: > On Mon, Oct 12, 2020 at 7:14 AM Ingo Molnar <mi...@kernel.org> 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
