Re: [PATCH slab/for-next v4 4/8] mm/slab: extend deferred free mechanism to handle rcu sheaves

[Harry Yoo]

On 7/23/26 7:27 PM, hu.shengming@xxxxxxxxxx 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 <ast@xxxxxxxxxx>
>> Reviewed-by: Pedro Falcato <pfalcato@xxxxxxx>
>> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
>> Signed-off-by: Harry Yoo (Oracle) <harry@xxxxxxxxxx>
>> ---
>>  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/20260624-kmalloc-nolock-fixes-v1-4-fdf4d17351dd@xxxxxxxxxx/
> 
> thanks,
> 
> --
> With Best Regards,
> Shengming

-- 
Cheers,
Harry / Hyeonggon

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature