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. > 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. > [1] > https://lore.kernel.org/all/[email protected]/ > > thanks, > > -- > With Best Regards, > Shengming -- Cheers, Harry / Hyeonggon
OpenPGP_signature.asc
Description: OpenPGP digital signature
