On Wed, Feb 11, 2026 at 08:26:54PM +0900, Harry Yoo wrote: > On Wed, Feb 11, 2026 at 11:53:46AM +0100, Uladzislau Rezki wrote: > > On Wed, Feb 11, 2026 at 07:44:37PM +0900, Harry Yoo wrote: > > > On Wed, Feb 11, 2026 at 11:16:51AM +0100, Uladzislau Rezki wrote: > > > > If this is supposed to be invoked from NMI, should we better just detect > > > > such context in the kvfree_call_rcu()? There are lot of "allow_spin" > > > > checks > > > > which make it easy to get lost. > > > > > > Detecting if it's NMI might be okay, but IIUC re-entrancy requirement > > > not only comes from NMI but also from attaching bpf programs to > > > kernel functions, something like: > > > > > > "Run a BPF program whenever queue_delayed_work() is called, > > > ... and the BPF program somehow frees memory via kfree_rcu_nolock()". > > > > > > Then, by the time the kernel calls queue_delayed_work() while holding > > > krcp->lock, it run the BPF program and calls kfree_rcu_nolock(), > > > it is not allowed to spin on krcp->lock. > > > > > > > > > > As i see you maintain llist and the idea is simply to re-enter to the > > > > kvfree_rcu() again with allow-spin=true, since then it will be "normal" > > > > context. > > > > > > It tries to acquire the lock and add it to krcp->head, but if somebody > > > is already holding the lock, it re-runs kvfree_rcu() with irq work. > > > > > > > Check no_spin on entry, if true, llist_add, queue-irq-work. Re-enter. > > That is much simpler! Actually, I tried this way during the initial > implementation. I like its simplicity. > > But I wasn't sure about performance implications of the approach > and switched to current implementation. > > It'd be nice to hear Alexei's thoughts on this; I think he'd have some > insights on performance aspect of this, as we have something similar > in slab (defer_free). > > > You might need to set-up interval to prevent frequent bouncing. > > You mean an interval to wait after queueing the work, before it gets > processed, right? > Something like that. Not ping a scheduler as soon as we added an object to be freed after GP.
-- Uladzislau Rezki
