From: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org> To: linux-arm-kernel@lists.infradead.org, tsoni@codeaurora.org, ckadabi@codeaurora.org, rishabhb@codeaurora.org, linux-kernel@vger.kernel.org, robh@kernel.org, hoeun.ryu@gmail.com, adobriyan@gmail.com, zhizhouzhang@asrmicro.com, suzuki.poulose@arm.com, mark.rutland@arm.com, james.morse@arm.com, will.deacon@arm.com, catalin.marinas@arm.com Cc: Abhimanyu Kapur <abhimany@codeaurora.org>, Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org> Subject: [PATCH] ARM64: smp: Fix cpu_up() racing with sys_reboot Date: Thu, 19 Jul 2018 15:18:46 -0700 [thread overview] Message-ID: <1532038726-3376-1-git-send-email-vnkgutta@codeaurora.org> (raw) Nothing stops a process from hotplugging in a CPU concurrently with a sys_reboot() call. In such a situation we could have ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the fact that the CPU is not really offline and call the CPU_UP_PREPARE notifier. When this happens stop_machine code will complain that the cpu thread already exists and BUG_ON(). CPU0 CPU1 sys_reboot() kernel_restart() machine_restart() machine_shutdown() smp_send_stop() ... ipi_cpu_stop() set_cpu_online(1, false) local_irq_disable() while(1) <PREEMPT> cpu_up() _cpu_up() if (!cpu_online(1)) __cpu_notify(CPU_UP_PREPARE...) cpu_stop_cpu_callback() BUG_ON(stopper->thread) This is easily reproducible by hotplugging in and out in a tight loop while also rebooting. Since the CPU is not really offline and hasn't gone through the proper steps to be marked as such, let's mark the CPU as inactive. This is just as easily testable as online and avoids any possibility of _cpu_up() trying to bring the CPU back online when it never was offline to begin with. Based on the similar patchset by for arm targets 040c163( "ARM: smp: Fix cpu_up() racing with sys_reboot)" Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org> Signed-off-by: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org> --- arch/arm64/kernel/smp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index 2faa986..adee4d3 100644 --- a/arch/arm64/kernel/smp.c +++ b/arch/arm64/kernel/smp.c @@ -790,7 +790,7 @@ void arch_irq_work_raise(void) */ static void ipi_cpu_stop(unsigned int cpu) { - set_cpu_online(cpu, false); + set_cpu_active(cpu, false); local_daif_mask(); sdei_mask_local_cpu(); @@ -925,10 +925,10 @@ void smp_send_stop(void) /* Wait up to one second for other CPUs to stop */ timeout = USEC_PER_SEC; - while (num_online_cpus() > 1 && timeout--) + while (num_active_cpus() > 1 && timeout--) udelay(1); - if (num_online_cpus() > 1) + if (num_active_cpus() > 1) pr_warning("SMP: failed to stop secondary CPUs %*pbl\n", cpumask_pr_args(cpu_online_mask)); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: vnkgutta@codeaurora.org (Venkata Narendra Kumar Gutta) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM64: smp: Fix cpu_up() racing with sys_reboot Date: Thu, 19 Jul 2018 15:18:46 -0700 [thread overview] Message-ID: <1532038726-3376-1-git-send-email-vnkgutta@codeaurora.org> (raw) Nothing stops a process from hotplugging in a CPU concurrently with a sys_reboot() call. In such a situation we could have ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the fact that the CPU is not really offline and call the CPU_UP_PREPARE notifier. When this happens stop_machine code will complain that the cpu thread already exists and BUG_ON(). CPU0 CPU1 sys_reboot() kernel_restart() machine_restart() machine_shutdown() smp_send_stop() ... ipi_cpu_stop() set_cpu_online(1, false) local_irq_disable() while(1) <PREEMPT> cpu_up() _cpu_up() if (!cpu_online(1)) __cpu_notify(CPU_UP_PREPARE...) cpu_stop_cpu_callback() BUG_ON(stopper->thread) This is easily reproducible by hotplugging in and out in a tight loop while also rebooting. Since the CPU is not really offline and hasn't gone through the proper steps to be marked as such, let's mark the CPU as inactive. This is just as easily testable as online and avoids any possibility of _cpu_up() trying to bring the CPU back online when it never was offline to begin with. Based on the similar patchset by for arm targets 040c163( "ARM: smp: Fix cpu_up() racing with sys_reboot)" Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org> Signed-off-by: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org> --- arch/arm64/kernel/smp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index 2faa986..adee4d3 100644 --- a/arch/arm64/kernel/smp.c +++ b/arch/arm64/kernel/smp.c @@ -790,7 +790,7 @@ void arch_irq_work_raise(void) */ static void ipi_cpu_stop(unsigned int cpu) { - set_cpu_online(cpu, false); + set_cpu_active(cpu, false); local_daif_mask(); sdei_mask_local_cpu(); @@ -925,10 +925,10 @@ void smp_send_stop(void) /* Wait up to one second for other CPUs to stop */ timeout = USEC_PER_SEC; - while (num_online_cpus() > 1 && timeout--) + while (num_active_cpus() > 1 && timeout--) udelay(1); - if (num_online_cpus() > 1) + if (num_active_cpus() > 1) pr_warning("SMP: failed to stop secondary CPUs %*pbl\n", cpumask_pr_args(cpu_online_mask)); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
next reply other threads:[~2018-07-19 22:18 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-19 22:18 Venkata Narendra Kumar Gutta [this message] 2018-07-19 22:18 ` [PATCH] ARM64: smp: Fix cpu_up() racing with sys_reboot Venkata Narendra Kumar Gutta 2018-07-19 22:55 ` Russell King - ARM Linux 2018-07-19 22:55 ` Russell King - ARM Linux 2018-07-20 6:23 ` Mark Rutland 2018-07-20 6:23 ` Mark Rutland
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=1532038726-3376-1-git-send-email-vnkgutta@codeaurora.org \ --to=vnkgutta@codeaurora.org \ --cc=abhimany@codeaurora.org \ --cc=adobriyan@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=ckadabi@codeaurora.org \ --cc=hoeun.ryu@gmail.com \ --cc=james.morse@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=rishabhb@codeaurora.org \ --cc=robh@kernel.org \ --cc=suzuki.poulose@arm.com \ --cc=tsoni@codeaurora.org \ --cc=will.deacon@arm.com \ --cc=zhizhouzhang@asrmicro.com \ /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: linkBe 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.