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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgYr6DHdK1p5RTa4yemf=6t86UtRnY4VhKjcvovBxO_hw@mail.gmail.com>
Date:   Mon, 12 Oct 2020 14:59:41 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] RCU changes for v5.10

On Mon, Oct 12, 2020 at 2:44 PM Paul E. McKenney <paulmck@...nel.org> wrote:
>
> So that RCU can tell, even in CONFIG_PREEMPT_NONE=y kernels, whether it
> is safe to invoke the memory allocator.

So in what situation is RCU called from random contexts that it can't even tell?

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

Well, AT A MINIMUM, the pull request should damn well have made it
1000% clear that this removes a case that has existed for decades, and
that potentially makes a difference for small kernels in particular.

In fact, my personal config option - still to this day - is
CONFIG_PREEMPT_VOLUNTARY and on the kernel I'm running,
CONFIG_PREEMPT_COUNT isn't actually set.

Because honestly, the code generation of some core code looks better
that way (in places where I've historically looked at things), and the
latency arguments against it simply aren't relevant when you have 8
cores or more.

So i don't think that "make preempt count unconditional" is some small
meaningless detail.

What is so magical about RCU allocating memory? I assume it's some
debug case? Why does that debug case then have a

    select PREEMPT_COUNT

like is done for PROVE_LOCKING?

> 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:

I had already raised my concerns when that patch series was posted by
Thomas originally. I did not feel like I needed to re-raise them just
because the series got reposted by somebody else.

                Linus