Re: + lazy-tlb-fix-hotplug-exit-race-with-mmu_lazy_tlb_shootdown.patch added to mm-hotfixes-unstable branch

[Nicholas Piggin]

On Tue Jun 20, 2023 at 4:32 PM AEST, Thomas Gleixner wrote:
> On Tue, Jun 20 2023 at 16:02, Nicholas Piggin wrote:
> > On Sun Jun 11, 2023 at 5:29 AM AEST, Thomas Gleixner wrote:
> >> /*
> >>  * Invoked on the outgoing CPU in context of the CPU hotplug thread
> >>  * after ensuring that there are no user space tasks left on the CPU.
> >>  *
> >>  * If there is a lazy mm in use on the hotplug thread, drop it and
> >>  * switch to init_mm.
> >>  *
> >>  * The reference count on init_mm is dropped in finish_cpu().
> >>  */
> >> static void sched_force_init_mm(void)
> >> {
> >>
> >> No?
> >
> > It could be done in many places. Peter touched it last and it's
> > been in the tree since prehistoric times.
>
> That's an argument for slapping it into some randomly chosen place and
> be done with it, right?

Ah, not exactly but I did misremember, I did have to change where I
added it so it does turn out to be more arbitrary than I thought.

If it goes in wait empty then than state is no longer wait empty, it's
wait empty and switch mm. I can put it there, should I also rename the
state?

> >> > +/*
> >> > + * After the CPU is offline, double check that it was previously switched to
> >> > + * init_mm. This call can be removed because the condition is caught in
> >> > + * finish_cpu() as well.
> >>
> >> So why adding it in the first place?
> >>
> >> The changelog mumbles something about reducing churn, but I fail to see
> >> that reduction. This adds 10 lines of pointless code and comments for
> >> zero value.
> >
> > Not sure what you're talking about. The patch didn't add it. Removing it
> > requires removing it from all archs, which is the churn.
>
> Sure. That's left as an exercise for others, right?

No, I'm telling you why I left the function in. Did not want to gate a
fix behind herding the arch cats. I will send the trivial patch to arch
trees after it's upstream. This is how such API changes are typically
done.

Thanks,
Nick