On Tue, Oct 22, 2024 at 10:55 AM Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > On 2024-10-22 12:14, Jordan Rife wrote: > > I assume this patch isn't meant to fix the related issues with freeing > > BPF programs/links with call_rcu? > > No, indeed. I notice that bpf_link_free() uses a prog->sleepable flag to > choose between: > > if (sleepable) > call_rcu_tasks_trace(&link->rcu, bpf_link_defer_dealloc_mult_rcu_gp); > else > call_rcu(&link->rcu, bpf_link_defer_dealloc_rcu_gp); > > But the faultable syscall tracepoint series does not require syscall programs > to be sleepable. So some changes may be needed on the ebpf side there. Your fix now adds a chain of call_rcu -> call_rcu_tasks_trace -> kfree, which should work regardless of sleepable/non-sleepable. For the BPF-side, yes, we do different things depending on prog->sleepable (adding extra call_rcu_tasks_trace for sleepable, while still keeping call_rcu in the chain), so the BPF side should be good, I think. > > > > > On the BPF side I think there needs to be some smarter handling of > > when to use call_rcu or call_rcu_tasks_trace to free links/programs > > based on whether or not the program type can be executed in this > > context. Right now call_rcu_tasks_trace is used if the program is > > sleepable, but that isn't necessarily the case here. Off the top of my > > head this would be BPF_PROG_TYPE_RAW_TRACEPOINT and > > BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE, but may extend to > > BPF_PROG_TYPE_TRACEPOINT? I'll let some of the BPF folks chime in > > here, as I'm not entirely sure. >
