On Sat, 23 Nov 2024 03:39:45 +0000 Ruan Bonan <bonan.r...@u.nus.edu> wrote:
> > vprintk_emit+0x414/0xb90 kernel/printk/printk.c:2406 > _printk+0x7a/0xa0 kernel/printk/printk.c:2432 > fail_dump lib/fault-inject.c:46 [inline] > should_fail_ex+0x3be/0x570 lib/fault-inject.c:154 > strncpy_from_user+0x36/0x230 lib/strncpy_from_user.c:118 > strncpy_from_user_nofault+0x71/0x140 mm/maccess.c:186 > bpf_probe_read_user_str_common kernel/trace/bpf_trace.c:215 [inline] > ____bpf_probe_read_user_str kernel/trace/bpf_trace.c:224 [inline] Hmm, this is a combination issue of BPF and fault injection. static void fail_dump(struct fault_attr *attr) { if (attr->verbose > 0 && __ratelimit(&attr->ratelimit_state)) { printk(KERN_NOTICE "FAULT_INJECTION: forcing a failure.\n" "name %pd, interval %lu, probability %lu, " "space %d, times %d\n", attr->dname, attr->interval, attr->probability, atomic_read(&attr->space), atomic_read(&attr->times)); This printk() acquires console lock under rq->lock has been acquired. This can happen if we use fault injection and trace event too because the fault injection caused printk warning. I think this should be a bug of the fault injection, not tracing/BPF. And to solve this issue, we may be able to check the context and if it is tracing/NMI etc, fault injection should NOT make it failure. Thank you, -- Masami Hiramatsu (Google) <mhira...@kernel.org>