All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: kexec@lists.infradead.org
Subject: [PATCH] kexec: disable cpu hotplug until the rebooting cpu is stable
Date: Wed, 26 Jan 2022 15:06:39 +0000	[thread overview]
Message-ID: <87tudq35a8.mognet@arm.com> (raw)
In-Reply-To: <CAFgQCTvbsh5UhefhDgOu8ZdUKww6FQXw-Hxnz5mC4vs0C+WP1w@mail.gmail.com>

On 26/01/22 10:45, Pingfan Liu wrote:
> On Wed, Jan 26, 2022 at 12:29 AM Valentin Schneider
> <valentin.schneider@arm.com> wrote:
>>
>> On 25/01/22 11:39, Pingfan Liu wrote:
>> > The following identical code piece appears in both
>> > migrate_to_reboot_cpu() and smp_shutdown_nonboot_cpus():
>> >
>> >       if (!cpu_online(primary_cpu))
>> >               primary_cpu = cpumask_first(cpu_online_mask);
>> >
>> > Although the kexec-reboot task can get through a cpu_down() on its cpu,
>> > this code looks a little confusing.
>> >
>> > Make things straight forward by keep cpu hotplug disabled until
>> > smp_shutdown_nonboot_cpus() holds cpu_add_remove_lock. By this way, the
>> > rebooting cpu can keep unchanged.
>> >
>>
>> So is this supposed to be a refactor with no change in behaviour? AFAICT it
>> actually does change things (and isn't necessarily clearer).
>>
> Yes, as you have seen, it does change behavior. Before this patch,
> there is a breakage:
>   migrate_to_reboot_cpu();
>   cpu_hotplug_enable();
>                                      ----------> technical, here can
> comes a cpu_down(this_cpu)
>   machine_shutdown();
>
> And this patch squeezes out this breakage.
>

Ok, that's worth pointing out in the changelog.

>> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> > index 68480f731192..db4fa6b174e3 100644
>> > --- a/kernel/kexec_core.c
>> > +++ b/kernel/kexec_core.c
>> > @@ -1168,14 +1168,12 @@ int kernel_kexec(void)
>> >               kexec_in_progress = true;
>> >               kernel_restart_prepare("kexec reboot");
>> >               migrate_to_reboot_cpu();
>> > -
>> >               /*
>> > -              * migrate_to_reboot_cpu() disables CPU hotplug assuming that
>> > -              * no further code needs to use CPU hotplug (which is true in
>> > -              * the reboot case). However, the kexec path depends on using
>> > -              * CPU hotplug again; so re-enable it here.
>> > +              * migrate_to_reboot_cpu() disables CPU hotplug. If an arch
>> > +              * relies on the cpu teardown to achieve reboot, it needs to
>> > +              * re-enable CPU hotplug there.
>> >                */
>> > -             cpu_hotplug_enable();
>> > +
>>
>> Not all archs map machine_shutdown() to smp_shutdown_nonboot_cpus(), other
>> archs will now be missing a cpu_hotplug_enable() prior to a kexec
>> machine_shutdown(). That said, AFAICT none of those archs rely on the
>> hotplug machinery in machine_shutdown(), so it might be OK, but that's not
>> obvious at all.
>>
> At the first glance, it may be not obvious, but tracing down
> cpu_hotplug_enable() to the variable cpu_hotplug_disabled, you can
> find out the limited involved functions are all related to
> cpu_up/cpu_down.
>
> IOW, if no code path connects with the interface of cpu_up/cpu_down,
> then kexec-reboot will not be affected.
>

That's my point, this only works if the other archs truly do not rely on
hotplug for machine_shutdown(), which seems to be the case but it wouldn't
hurt for you to double-check that and explicitely call it out in the
changelog.

> And after this patch, it is more clear how to handle the following cases:
> arch/arm/kernel/reboot.c:94:    smp_shutdown_nonboot_cpus(reboot_cpu);
> arch/arm64/kernel/process.c:88: smp_shutdown_nonboot_cpus(reboot_cpu);
> arch/ia64/kernel/process.c:578: smp_shutdown_nonboot_cpus(reboot_cpu);
>

FWIW riscv is also concerned.

> Thanks,
> Pingfan


  reply	other threads:[~2022-01-26 15:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25  3:39 [PATCH] kexec: disable cpu hotplug until the rebooting cpu is stable Pingfan Liu
2022-01-25 16:29 ` Valentin Schneider
2022-01-26  2:45   ` Pingfan Liu
2022-01-26 15:06     ` Valentin Schneider [this message]
2022-01-27  8:44       ` Pingfan Liu

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=87tudq35a8.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=kexec@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.