On Tue, Dec 10, 2024 at 7:21 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Tue, Dec 10, 2024 at 03:48:32PM +0100, Usama Saqib wrote: > > Thanks for your reply. It is correct that the problem I shared is > > already present under PREEMPT_FULL, and as such there is no new issue > > being introduced by PREEMPT_LAZY. This is not an issue of PREEMPTY_LAZY. Global bpf_prog_active counter that prevents nesting of bpf progs attached to kprobes is a bpf side issue. As we mentioned earlier we're working on resilient spin locks that will convert bpf maps to use this new resilient spin lock. At this point we will be able to convert global bpf_prog_active counter to per-program recursion protection counter, so that single prog cannot nest, but different progs don't interfere with each other. We already use a per-prog counter for raw_tp progs, but vanilla tp progs rely on a global counter. > > My main concern is that if PREEMPT_LAZY is intended to become the > > default mode (please correct me if I am wrong here) before this > > problem is addressed in the BPF subsystem, then this would result in a > > big regression for us. This is especially true if distros pick up the > > changes in the intervening period. I wanted to draw attention to this > > issue so this situation does not happen. > > Fair enough; I think it'll be a few releases before LAZY is in any shape > to be considered a replacement in any case. Quite a lot of cond_resched > (ab)use needs to be audited, Live-patching needs a bit of TLC and so on. Sure, but please don't wait for bpf to enable PREEMPT_LAZY. bpf quirks should never be in the way of core kernel development.
