On Thu, Feb 06, 2025 at 02:54:08AM -0800, Kumar Kartikeya Dwivedi wrote: > Additionally, eBPF programs attached to different parts of the kernel > can introduce new control flow into the kernel, which increases the > likelihood of deadlocks in code not written to handle reentrancy. There > have been multiple syzbot reports surfacing deadlocks in internal kernel > code due to the diverse ways in which eBPF programs can be attached to > different parts of the kernel. By switching the BPF subsystem’s lock > usage to rqspinlock, all of these issues can be mitigated at runtime. Only if the called stuff is using this new lock. IIRC we've had a number of cases where eBPF was used to tie together 'normal' kernel functions in a way that wasn't sound. You can't help there. As an example, eBPF calling strncpy_from_user(), which ends up in fault injection and badness happens -- this has been since fixed, but still.
