diff options
| author | Xi Ruoyao <xry111@xry111.site> | 2026-03-16 10:36:01 +0800 |
|---|---|---|
| committer | Huacai Chen <chenhuacai@loongson.cn> | 2026-03-16 10:36:01 +0800 |
| commit | 8a69d02481ff97683952e94b9d1eae29b45f88fd (patch) | |
| tree | b6f692a21e17b01e72244c6280b974df57023d2a /include/uapi/linux/wimax/git@git.tavy.me:linux.git | |
| parent | c8b8f3c50f487b145433a6c3f95efd8790079a06 (diff) | |
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>
Diffstat (limited to 'include/uapi/linux/wimax/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions
