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: <87362ipjsr.fsf@nanos.tec.linutronix.de>
Date:   Tue, 13 Oct 2020 11:16:52 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] RCU changes for v5.10

Linus,

On Mon, Oct 12 2020 at 13:25, Linus Torvalds wrote:
> 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.

Yes, we agreed on those parts and also started to act on your request to
remove these constructs where non core code is changing behaviour
depending on some context check by either seperating it or handing the
condition in from the call sites.

You said in that original discussion:

> Of course core code can (and will) look at things like
>
>	if (in_interrupt())
>	    .. schedule work asynchronously ..
>
>  because core code ends up being called from odd places, and code like
>  that is expected to have understanding of the rules it plays with.
>
>  But something like RCU is a very different beast from some "walk the
>  scatter-gather list" code.
>
>  RCU does its work in the background, and works with lots of different
>  things. And it's so core and used everywhere that it knows about these
>  things. I mean, we literally have special code explicitly to let RCU
>  know "we entered kernel context now".

As Paul was facing the problem of not knowing the exact context on
PREEMPT_NONE kernels which can aside of the raw spinlock issue cause
deadlocks vs. the page allocator, we had the impression that solving
this particular itch with a consistent preempt count was justified.

As you did not voice objections on Pauls series which incorporated my
initial work, I was encouraging Paul to go ahead with this. Of course if
I misinterpreted your silence on that patch submission, I need to fine
tune my void decoder.

That said, I fully agree that this all should have been part of the pull
request message and in hindsight I should have reminded Ingo to be very
careful about that when we were splitting up the pull request pile of
the tip tree.

I hope that clarifies the context some more and makes the whole thing
more palatable.

Thanks,

        tglx

/me goes back to stare at in_*() constructs...