]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
LoongArch: Fix calling smp_processor_id() in preemptible code
authorXi Ruoyao <xry111@xry111.site>
Mon, 16 Mar 2026 02:36:01 +0000 (10:36 +0800)
committerHuacai Chen <chenhuacai@loongson.cn>
Mon, 16 Mar 2026 02:36:01 +0000 (10:36 +0800)
commit8a69d02481ff97683952e94b9d1eae29b45f88fd
treeb6f692a21e17b01e72244c6280b974df57023d2a
parentc8b8f3c50f487b145433a6c3f95efd8790079a06
LoongArch: Fix calling smp_processor_id() in preemptible code

Fix the warning:

  BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
  caller is larch_insn_text_copy+0x40/0xf0

Simply changing it to raw_smp_processor_id() is not enough: if preempt
and CPU hotplug happens after raw_smp_processor_id() but before calling
stop_machine(), the CPU where raw_smp_processor_id() has run may become
offline when stop_machine() and no CPU will run copy_to_kernel_nofault()
in text_copy_cb().  Thus guard the larch_insn_text_copy() calls with
cpus_read_lock() and change stop_machine() to stop_machine_cpuslocked()
to prevent this.

I've considered moving the locks inside larch_insn_text_copy() but
doing so seems not an easy hack. In bpf_arch_text_poke() obviously the
memcpy() call must be guarded by text_mutex, so we have to leave the
acquire of text_mutex out of larch_insn_text_copy(). But in the entire
kernel the acquire of mutexes is always after cpus_read_lock(), so we
cannot put cpus_read_lock() into larch_insn_text_copy() while leaving
the text_mutex acquire out (or we risk a deadlock due to inconsistent
lock acquire order). So let's fix the bug first and leave the posssible
refactor as future work.

Fixes: 9fbd18cf4c69 ("LoongArch: BPF: Add dynamic code modification support")
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
arch/loongarch/kernel/inst.c
arch/loongarch/net/bpf_jit.c