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: [email protected]
> Closes: 
> https://lore.kernel.org/all/[email protected]/
> Fixes: 1bc7896e9ef4 ("bpf: Fix deadlock with rq_lock in bpf_send_signal()")
> Signed-off-by: Puranjay Mohan <[email protected]>
> ---
>  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.
>                */


Reply via email to