public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Thomas Gleixner" <tglx@linutronix.de>,
	<linux-kernel@vger.kernel.org>, <mm-commits@vger.kernel.org>,
	<torvalds@linux-foundation.org>, <peterz@infradead.org>,
	<akpm@linux-foundation.org>
Subject: Re: + lazy-tlb-fix-hotplug-exit-race-with-mmu_lazy_tlb_shootdown.patch added to mm-hotfixes-unstable branch
Date: Tue, 20 Jun 2023 16:02:02 +1000	[thread overview]
Message-ID: <CTH8ZNDRMLEZ.2WS18IS2E38T7@wheely> (raw)
In-Reply-To: <87v8fv86bh.ffs@tglx>

On Sun Jun 11, 2023 at 5:29 AM AEST, Thomas Gleixner wrote:
> On Thu, May 25 2023 at 13:52, Andrew Morton wrote:
>
> Replying here as I wasn't cc'ed on the patch.
>
> > @@ -1030,6 +1031,8 @@ static int take_cpu_down(void *_param)
> >  	enum cpuhp_state target = max((int)st->target, CPUHP_AP_OFFLINE);
> >  	int err, cpu = smp_processor_id();
> >  
> > +	idle_task_prepare_exit();
> > +
> >  	/* Ensure this CPU doesn't handle any more interrupts. */
> >  	err = __cpu_disable();
> >  	if (err < 0)
> > --- a/kernel/sched/core.c~lazy-tlb-fix-hotplug-exit-race-with-mmu_lazy_tlb_shootdown
> > +++ a/kernel/sched/core.c
> > @@ -9373,19 +9373,33 @@ void sched_setnuma(struct task_struct *p
> >   * Ensure that the idle task is using init_mm right before its CPU goes
> >   * offline.
> >   */
> > -void idle_task_exit(void)
> > +void idle_task_prepare_exit(void)
>
> This function name along with the above comment is completely
> misleading. It suggests this is about the idle task itself instead of
> making it clear that this ensures that the kernel threads of the
> outgoing CPU are not longer using a mm which is not init_mm.
>
> The callsite is arbitratily chosen too. Why does this have to be done
> from stomp machine context?

It's the minimalish fix. My patch didn't change what that idle_task_exit
is attempting to do.

> There is zero reason to do so. The last hotplug state before teardown is
> CPUHP_AP_SCHED_WAIT_EMPTY. It invokes sched_cpu_wait_empty() in the
> context of the CPU hotplug thread of the outgoing CPU.
>
> sched_cpu_wait_empty() guarantees that there are no temporarily pinned
> (via migrate disable) user space tasks on that CPU anymore. The
> scheduler guarantees that there won't be user space tasks woken up on or
> migrated to that CPU because the CPU is not in the cpu_active mask.
>
> The stopper thread has absolutely nothing to do with that.
>
> So sched_cpu_wait_empty() is the obvious place to handle that:
>
> int sched_cpu_wait_empty(unsigned int cpu)
> {
> 	balance_hotplug_wait();
> +	sched_force_init_mm();
> 	return 0;
> }
>
> And then have:
>
> /*
>  * 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.

> >  {
> >  	struct mm_struct *mm = current->active_mm;
> >  
> > -	BUG_ON(cpu_online(smp_processor_id()));
> > -	BUG_ON(current != this_rq()->idle);
> > +	WARN_ON(!irqs_disabled());
> >  
> >  	if (mm != &init_mm) {
> > -		switch_mm(mm, &init_mm, current);
> > +		mmgrab_lazy_tlb(&init_mm);
> > +		current->active_mm = &init_mm;
> > +		switch_mm_irqs_off(mm, &init_mm, current);
> >  		finish_arch_post_lock_switch();
> > +		mmdrop_lazy_tlb(mm);
> >  	}
> > +	/* finish_cpu() will mmdrop the init_mm ref after this CPU stops */
> > +}
> > +
> > +/*
> > + * 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.

Thanks,
Nick

  reply	other threads:[~2023-06-20  6:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230525205253.E2FAEC433EF@smtp.kernel.org>
2023-06-10 19:29 ` + lazy-tlb-fix-hotplug-exit-race-with-mmu_lazy_tlb_shootdown.patch added to mm-hotfixes-unstable branch Thomas Gleixner
2023-06-20  6:02   ` Nicholas Piggin [this message]
2023-06-20  6:32     ` Thomas Gleixner
2023-06-20  8:10       ` Nicholas Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CTH8ZNDRMLEZ.2WS18IS2E38T7@wheely \
    --to=npiggin@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox