Hi, On 1/15/2025 6:36 PM, Puranjay Mohan wrote: > 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@xxxxxxxxxxxxxxxxxxxxxxxxx > Closes: https://lore.kernel.org/all/67486b09.050a0220.253251.0084.GAE@xxxxxxxxxx/ > Fixes: 1bc7896e9ef4 ("bpf: Fix deadlock with rq_lock in bpf_send_signal()") > Signed-off-by: Puranjay Mohan <puranjay@xxxxxxxxxx> > --- > 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. > */
