Harry wrote: > On 7/23/26 7:27 PM, [email protected] wrote: > > Harry wrote: > >> __kfree_rcu_sheaf() cannot invoke call_rcu() when spinning is not > >> allowed and IRQs are disabled. To relax the limitation, extend the > >> deferred free fallback so that a full rcu sheaf can be submitted to > >> call_rcu() via the existing IRQ work. > >> > >> Since the deferred mechanism does more than deferred freeing of objects, > >> rename the struct to deferred_percpu_work and adjust names accordingly. > >> > >> When a sheaf is queued on an IRQ work, it is detached from > >> pcs->rcu_free but call_rcu() is not invoked until the irq_work runs. > >> To keep the kvfree_rcu barrier's promise, call irq_work_sync() on each > >> CPU before calling rcu_barrier(). > >> > >> In the meantime, remove the TODO item as apparently there is no simple > >> and effective way to achieve that. This is because, unlike sheaves, > >> kfree_rcu() batches objects from different caches together. > >> > >> Suggested-by: Alexei Starovoitov <[email protected]> > >> Reviewed-by: Pedro Falcato <[email protected]> > >> Reviewed-by: Vlastimil Babka (SUSE) <[email protected]> > >> Signed-off-by: Harry Yoo (Oracle) <[email protected]> > >> --- > >> mm/slab.h | 2 +- > >> mm/slab_common.c | 7 ++--- > >> mm/slub.c | 85 > >> +++++++++++++++++++++++++++++++++----------------------- > >> 3 files changed, 53 insertions(+), 41 deletions(-) > >> > >> diff --git a/mm/slab_common.c b/mm/slab_common.c > >> index e07b4e6d6679..9c9ae1384f47 100644 > >> --- a/mm/slab_common.c > >> +++ b/mm/slab_common.c > >> @@ -551,7 +551,7 @@ void kmem_cache_destroy(struct kmem_cache *s) > >> } > >> > >> /* Wait for deferred work from kmalloc/kfree_nolock() */ > >> - defer_free_barrier(); > >> + deferred_work_barrier(); > >> > >> cpus_read_lock(); > >> mutex_lock(&slab_mutex); > > > > Hi Harry, > > Hi Shengming, > > > I noticed that your fix in [1] serializes defer_free_barrier() to > > avoid concurrent irq_work_sync() waiters. > > Right. > > > However, this patch still calls the renamed deferred_work_barrier() > > outside that serialization scope, including the new call sites in > > kvfree_rcu_barrier_on_cache() and flush_all_rcu_sheaves(). > > Good point! > > I didn't _fix_ that as part of this patch since that would be confusing > and the fix didn't land the mainline or slab yet.
Thanks for the clarification! > > Is this series expected to depend on [1], with these call sites > > moved under the same serialization? Or am I missing something? > > I was thinking of rebasing the fixes as there won't be much conflicts, > nobody except for sashiko complained about this, and we're not going to > backport them anyway. Rebasing the fixes sounds good to me. -- With Best Regards, Shengming
