diff options
| author | Aboorva Devarajan <aboorvad@linux.ibm.com> | 2026-06-05 11:29:12 +0300 |
|---|---|---|
| committer | Madhavan Srinivasan <maddy@linux.ibm.com> | 2026-06-15 13:55:21 +0300 |
| commit | 5c86f1c1f972761a04bf22f4c0618d1aa714185b (patch) | |
| tree | e4111df9a026d7f4d1bc0999dd13ce191c98c74f /include/linux | |
| parent | 0ecd26e93e698c8327521910fc6296f5b84a4b92 (diff) | |
| download | linux-5c86f1c1f972761a04bf22f4c0618d1aa714185b.tar.xz | |
powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus
kexec_prepare_cpus_wait() calls get_cpu() internally to obtain the
current CPU id. kexec_prepare_cpus() calls kexec_prepare_cpus_wait()
twice -- once for KEXEC_STATE_IRQS_OFF and once for
KEXEC_STATE_REAL_MODE -- but only issues a single put_cpu() at the end,
leaving preempt_count elevated by one extra nesting level.
In practice the imbalance does not trigger a 'scheduling while atomic'
splat because the kexec path is a one-way trip: IRQs are already
disabled, no schedule() occurs after the leak, and
default_machine_kexec() overwrites preempt_count with HARDIRQ_OFFSET
before jumping into kexec_sequence() which never returns. However the
bookkeeping is still wrong.
kexec_prepare_cpus() calls local_irq_disable()/hard_irq_disable()
before invoking kexec_prepare_cpus_wait(), so the CPU is already pinned
and the get_cpu()/put_cpu() preempt_disable() bracketing is unnecessary.
Only the current CPU id is needed, so replace get_cpu() with
raw_smp_processor_id() and drop the now-unneeded put_cpu().
Fixes: 1fc711f7ffb0 ("powerpc/kexec: Fix race in kexec shutdown")
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260605082912.305100-4-aboorvad@linux.ibm.com
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions
