> I don't have patches in front of me, so I'm guessing a bit. > So pls remind me where all these patches are? > What tree/branch are we talking about? I tested this in linux-next. Here is the patch series. Link: https://lore.kernel.org/bpf/20241009010718.2050182-1-mathieu.desnoyers@xxxxxxxxxxxx/T/#u > and in addition all tracepoints (both sleepable and not) > should deref __data under normal rcu_read_lock() before > passing that pointer into __bpf_trace_##call. > Because that's bpf link and prog are rcu protected. I think this is the crux of the issue. > #define __DO_TRACE_CALL(name, args) \ > do { \ > struct tracepoint_func *it_func_ptr; \ > void *__data; \ > it_func_ptr = \ > rcu_dereference_raw((&__tracepoint_##name)->funcs); \ > if (it_func_ptr) { \ > __data = (it_func_ptr)->data; \ > static_call(tp_func_##name)(__data, args); \ > } \ > } while (0) > #else This code now executes under rcu_read_lock_trace for syscall tracepoints where __data gets dereferenced but call_rcu is used to free non-sleepable programs/links inside bpf_link_free. Is it viable to just use rcu_read_lock()/rcu_read_unlock() here to denote an RCU read-side critical section around where __data is used? > We're not going to penalize all bpf progs for that. > This patch is a non-starter. Fair enough. This could probably be more targeted, using call_rcu_tasks_trace only for raw tracepoint programs or those attached to syscall tracepoints instead of doing this chaining for everything. That is, assuming a change here is even needed at all and that this issue can't be fixed outside of the BPF stuff. I'm not sure whether or not that's the case. -Jordan
