On Tue, Jan 13, 2026 at 6:23 AM Sebastian Andrzej Siewior <[email protected]> wrote: > > On 2026-01-12 09:19:58 [-0800], Alexei Starovoitov wrote: > > > Now if you are saying that BPF will handle migrate_disable() on its own > > > and not require the tracepoint infrastructure to do it for it, then > > > this is perfect. And I can then simplify this code, and just use > > > srcu_fast for both RT and !RT. > > > > Agree. Just add migrate_disable to __bpf_trace_run, > > or, better yet, use rcu_read_lock_dont_migrate() in there. > > Wonderful, thank you. > > Is this "must remain on the same CPU and can be re-entrant" because BPF > core code such memory allocator/ data structures use per-CPU data > structures and must use the same through the whole invocation?
It's per-cpu maps. htab_percpu_map_lookup_elem() returns a pointer to per-cpu value which needs to be valid for the duration of the program. Not much else.
