On Thu, Oct 15, 2026 at 10:41 AM Amery Hung <[email protected]> wrote: > I think this fix is heading in the wrong direction. The struct_ops map > association was designed as an RCU-protected pointer: asynchronous > users may outlive the map and observe a NULL association. The existing > selftest explicitly verifies this behavior. > > The problem is that the disassociation now happens after the grace > period initiated by bpf_map_put(). Could we instead make > disassociation safe in map_free_pre_rcu(), before that existing grace > period, rather than adding another deferred-free path?
Agreed, that is simpler. v4 [1] does it in two steps: 1. Replace st_ops_assoc_mutex with a spinlock taken with irqs disabled, and put the map of a non-struct_ops prog after dropping it. map_free_pre_rcu() runs wherever the last reference is dropped, which can be softirq, e.g. bpf_struct_ops_put() from tcp_cleanup_congestion_control(). 2. Call bpf_struct_ops_map_dissoc_progs() from bpf_struct_ops_map_free_pre_rcu() instead of bpf_struct_ops_map_free(). One thing to confirm: bpf_map_put() waits only for a regular RCU grace period unless free_after_mult_rcu_gp is set, and no struct_ops sets it today. bpf_wq_work() runs the callback of a struct_ops prog under rcu_read_lock_trace(), and that callback can read the association too, so v4 sets free_after_mult_rcu_gp for every struct_ops map. Would you rather leave that to each struct_ops? On a KASAN kernel with v4, st_ops_assoc_in_timer_free passes 100 of 100 runs, where it hits the int3 Oops on run 1 without the fix, and lockdep reports nothing over the struct_ops and tcp_ca selftests. [1] https://lore.kernel.org/r/20261016-selftests-bpf-struct-ops-assoc-timer-v4-0-9ad31c212...@gmail.com
