On Sun, Nov 01, 2026 at 11:37 PM Feng Yang <[email protected]> wrote: > Route these paths to bpf_get_stack_sleepable() and mark the new protos > might_sleep, since build_id_parse() may fault in file data for > BPF_F_USER_STACK | BPF_F_USER_BUILD_ID. Sleepable programs that call > bpf_get_stack() from inside a bpf_rcu_read_lock() region are now rejected > by the verifier, which is the correct behavior for a helper that can > sleep.
That's a new feature. It's not a fix for the splat. Andrii's point in v1 is about build IDs. That's a good reason for this patch, but the splat needs Songsen's patch anyway: https://lore.kernel.org/bpf/[email protected]/ Songsen's patch this patch ------------------------------------ --------------- ------------- splat in sleepable progs fixed fixed splat in bpf_wq, task_work callbacks fixed still there build ID when the page is paged out no yes progs that load today all load some rejected Row 2: the callback is sleepable, but its prog is not. bpf_wq_work() rcu_read_lock_trace() only callback_fn() prog->sleepable == false bpf_get_task_stack() may_fault == false __bpf_get_stack() no rcu_read_lock() get_callchain_entry() rcu_dereference(): splat Row 4: sleepable fentry, lsm, iter, syscall and tracepoint progs that call bpf_get_stack() under bpf_rcu_read_lock() or bpf_preempt_disable() load fine today. With this patch the verifier rejects them. It does so even when flags don't have BPF_F_USER_BUILD_ID. Pls respin it as a feature, with a new subject and commit log and a selftest. pw-bot: cr
