Re: [BUG] bpf: Soft lockup / panic triggered by bpf_task_release_dtor from NMI on rcu_nocbs CPU

[Justin Suess <utilityemal77@gmail.com>]

On Tue, Apr 21, 2026 at 10:23:56PM +0200, Kumar Kartikeya Dwivedi wrote:
> On Tue, 21 Apr 2026 at 22:10, Justin Suess <utilityemal77@gmail.com> wrote:
> >
> > Hello,
> >
> > I found a reproducible soft lockup / panic involving BPF task kptr destruction from NMI context.
> >
> > It was found after further investigation from a Sashiko report on my patch:
> > https://lore.kernel.org/bpf/20260420203306.3107246-1-utilityemal77@gmail.com/T/#t
> >
> > The issue is reproducible with a BPF selftest-derived reproducer that:
> >
> > 1. Stores exited task references in a BPF hash map as refcounted task kptrs.
> > 2. Deletes those kptrs from a `tp_btf/nmi_handler` program.
> > 3. Runs on an `rcu_nocbs` CPU.
> >
> > In my setup this eventually triggers a soft lockup and panic in a workqueue thread stuck in:
> >
> > `perf_sched_delayed`
> > `  -> static_key_disable()`
> > `  -> arch_jump_label_transform_apply()`
> > `  -> smp_text_poke_batch_finish()`
> > `  -> on_each_cpu_cond_mask()`
> > `  -> smp_call_function_many_cond()`
> >
> > The triggering condition appears to be that `bpf_task_release_dtor()` can run in NMI context and reach the last-ref `put_task_struct_rcu_user()` path on an offloaded RCU callback CPU.
> >
> > Affected code path is a dtor triggered by deleting the last reference to a task_struct kptr:
> >
> > `bpf_map_delete_elem()`
> > `  -> htab_map_delete_elem()`
> > `  -> free_htab_elem()`
> > `  -> bpf_obj_free_fields()`
> > `  -> bpf_task_release_dtor()`
> > `  -> put_task_struct_rcu_user()`
> > `  -> call_rcu()`
> >
> > This is triggered from:
> >
> > `tp_btf/nmi_handler`
> > `  -> clear_task_kptrs_from_nmi` (reproducer bpf prog)
> >
> > Environment
> >
> > - x86_64 QEMU VM
> > - PREEMPT(full)
> > - `CONFIG_RCU_EXPERT=y`
> > - `CONFIG_RCU_NOCB_CPU=y`
> > - booted with `rcu_nocbs=1-7`
> >
> > [...]
> 
> Makes sense. I think the reasonable path is to just close usage in the
> NMI context, otherwise we must address each case. Could you try the
> attached diff and let me know if it successfully rejects kptr usage
> here? Thanks.
Didn't work for me.

is_tracing_prog_type, despite the name, does not return true
for BPF_PROG_TYPE_TRACING. Only BPF_PROG_TYPE_TRACEPOINT.

I'm honestly still not sure what the difference is, but they are
different [1]

Would you rather do this or just reject the dtors with a
kfunc filter for this program type?

Or teach the verifier that the kptr ops need to be offloaded with
bpf_task_work_schedule_resume_impl?

[1]: https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_TRACING/