Re: [PATCH v2 bpf] bpf: Replace bpf_map_kmalloc_node() with kmalloc_nolock() to allocate bpf_async_cb structures.

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Tue, Oct 14, 2025 at 6:59 PM Harry Yoo <harry.yoo@oracle.com> wrote:
>
> On Tue, Oct 14, 2025 at 05:07:00PM -0700, Alexei Starovoitov wrote:
> > From: Alexei Starovoitov <ast@kernel.org>
> >
> > The following kmemleak splat:
> > [    8.105530] kmemleak: Trying to color unknown object at 0xff11000100e918c0 as Black
> > [    8.106521] Call Trace:
> > [    8.106521]  <TASK>
> > [    8.106521]  dump_stack_lvl+0x4b/0x70
> > [    8.106521]  kvfree_call_rcu+0xcb/0x3b0
> > [    8.106521]  ? hrtimer_cancel+0x21/0x40
> > [    8.106521]  bpf_obj_free_fields+0x193/0x200
> > [    8.106521]  htab_map_update_elem+0x29c/0x410
> > [    8.106521]  bpf_prog_cfc8cd0f42c04044_overwrite_cb+0x47/0x4b
> > [    8.106521]  bpf_prog_8c30cd7c4db2e963_overwrite_timer+0x65/0x86
> > [    8.106521]  bpf_prog_test_run_syscall+0xe1/0x2a0
> >
> > happens due to the combination of features and fixes, but mainly due to
> > commit 6d78b4473cdb ("bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()")
> > It's using __GFP_HIGH, which instructs slub/kmemleak internals to skip
> > kmemleak_alloc_recursive() on allocation, so subsequent kfree_rcu()->
> > kvfree_call_rcu()->kmemleak_ignore() complains with the above splat.
> >
> > To fix this imbalance, replace bpf_map_kmalloc_node() with
> > kmalloc_nolock() and kfree_rcu() with call_rcu() + kfree_nolock() to
> > make sure that the objects allocated with kmalloc_nolock() are freed
> > with kfree_nolock() rather than the implicit kfree() that kfree_rcu()
> > uses internally.
> >
> > Note, the kmalloc_nolock() happens under bpf_spin_lock_irqsave(), so
> > it will always fail in PREEMPT_RT. This is not an issue at the moment,
> > since bpf_timers are disabled in PREEMPT_RT. In the future
> > bpf_spin_lock will be replaced with state machine similar to
> > bpf_task_work.
> >
> > Fixes: 6d78b4473cdb ("bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()")
> > Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
> > Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> > ---
>
> LGTM,
> Acked-by: Harry Yoo <harry.yoo@oracle.com>
>
> So we're losing benefit of batch-processing via kfree_rcu() and
> instead using call_rcu(), and I guess it's fine since it's not very
> performance critical

yes. Here freeing is not in critical path.

> so we don't have to make kfree_rcu() work with
> objects that are allocated via kmalloc_nolock()?

Not quite :) It's on the todo list.
Something like kfree_nolock_rcu() is needed, and
also SLAB_TYPESAFE_BY_RCU-like and new SLAB_TYPESAFE_BY_SRCU_FAST flag.
The plan for the upcoming merge window is to delete rcu tasks trace
and replace with srcu_fast. It will clarify next steps.