Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [GIT PULL] RCU changes for v5.10 | Date | Tue, 13 Oct 2020 11:16:52 +0200 |
| |
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...
| |