Re: [PATCH bpf-next v2 0/2] bpf: Fix sleepable check for tracing prog

[Leon Hwang <leon.hwang@linux.dev>]

On 31/7/26 08:07, Andrii Nakryiko wrote:
> On Sat, Jul 25, 2026 at 6:27 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> When CONFIG_FUNCTION_ERROR_INJECTION is disabled, a sleepable tracing prog
>> is allowed to attach to '__x64_'-alike prefix symbols.
>>
>> It is because the verifier does not verify whether the symbol is a kernel
>> function or a bpf prog. That said, a sleepable tracing prog is allowed to
>> attach to a bpf prog target whose name has '__x64_'-alike prefix.
>>
>> For example, a sleepable fentry prog attaches to a '__x64_sys_nop' XDP
> 
> we do have addr, so we should be able to distinguish between attaching
> to kernel function vs BPF program, no?


Yes, we can distinguish a bpf prog from a kernel function by addr.

I'd prefer passing 'tgt_prog' to btf_id_allow_sleepable() as a simple
change.

> 
>> prog, and copies buffer from a user pointer with bpf_copy_from_user()
>> helper. After attaching the XDP prog to lo interface, the kernel BUG
>> could be triggered by 'ping -c 1 -W 1 127.0.0.1':
>>
>> [    3.460756] BUG: sleeping function called from invalid context at kernel/bpf/trampoline.c:1324
>>
>> Fix it by disallowing sleepable tracing prog always when its target is
>> bpf prog.
> 
> what happens when we freplace sleepable BPF program/subprogram with
> another sleepable BPF subprogram? And same question for sleepable
> fentry/fexit program attaching to sleepable BPF program? Is it
> something that just cannot work or we can actually allow that?


Currently, sleepable freplace/fentry/fexit progs are already disallowed
from attaching to bpf prog, because btf_id_allow_sleepable() returns
-EINVAL for them (except for this BUG).

Since no one has proposed relaxing the restriction, I'd like to keep it
as-is when fixing this BUG.

I'm not sure whether allowing it would introduce any issue.

Thanks,
Leon

> [...]