Re: [PATCH bpf] bpf: trace: send signals asynchronously if !preemptible
From: Hou Tao <hidden>
Date: 2025-01-21 01:26:48
Also in:
bpf, lkml
Hi, On 1/15/2025 6:36 PM, Puranjay Mohan wrote:
quoted hunk ↗ jump to hunk
BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. So change `irqs_disabled()` to `!preemptible()` that covers all edge cases: preempt_count() == 0 and irqs_disabled() Reported-by: syzbot+97da3d7e0112d59971de@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67486b09.050a0220.253251.0084.GAE@google.com/ (local) Fixes: 1bc7896e9ef4 ("bpf: Fix deadlock with rq_lock in bpf_send_signal()") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> --- kernel/trace/bpf_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 1b8db5aee9d3..d162c87e09a8 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c@@ -853,7 +853,7 @@ static int bpf_send_signal_common(u32 sig, enum pid_type type, struct task_struc if (unlikely(is_global_init(task))) return -EPERM; - if (irqs_disabled()) { + if (!preemptible()) {
Should we unfold preemptible() to "preempt_count() == 0 && !irqs_disabled()" instead, because when preemption is disabled, preemptible() will evaluate as 0 and the irq_disabled() case will be skipped ?
/* Do an early check on signal validity. Otherwise, * the error is lost in deferred irq_work. */