lkml.org 
[lkml]   [2020]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] RCU changes for v5.10
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@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

\
 
 \ /
  Last update: 2020-10-12 23:45    [W:0.142 / U:1.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site