mirror of
https://github.com/torvalds/linux.git
synced 2026-09-14 16:10:02 +02:00
5c86f1c1f9
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:
|
||
|---|---|---|
| .. | ||
| core_32.c | ||
| core_64.c | ||
| core.c | ||
| crash.c | ||
| elf_64.c | ||
| file_load_64.c | ||
| file_load.c | ||
| Makefile | ||
| ranges.c | ||
| relocate_32.S | ||
| vmcore_info.c | ||