Re: [PATCH v4] mm/slub: use empty sheaf helpers for oversized sheaves

[Vlastimil Babka (SUSE)]

On 5/28/26 08:37, hu.shengming@xxxxxxxxxx wrote:
> VlastimilBabka(SUSE)<vbabka@xxxxxxxxxx> wrote:
>>On 5/27/26 15:48, hu.shengming@xxxxxxxxxx wrote:
>>
>> I see, thanks. Could we perhaps move the mark_obj_codetag_empty() code to
>> alloc_empty_sheaf()? If not, then do as you suggest?
>>
> 
> I looked at moving mark_obj_codetag_empty() to alloc_empty_sheaf(), but I
> don't think it is equivalent to doing it on the free path.
> 
> mark_obj_codetag_empty() only marks an entry if the slab already has
> slabobj_exts. For sheaf metadata allocated with __GFP_NO_OBJ_EXT, the
> allocation hook will not create the object extension. So if the slab has
> no obj_exts at allocation time, an allocation-time mark would be a no-op.
> A slabobj_ext can still be created later for the same kmalloc slab by
> another allocation, and then freeing the sheaf without marking it on the
> free path can still leave the sheaf entry with a NULL tag.

Ah right, makes sense.

> So I think the marking should stay in free_empty_sheaf(). I can still
> move the caller-GFP filtering out of __alloc_empty_sheaf(). That includes
> both clearing OBJCGS_CLEAR_MASK and handling the early rejection of
> caller-supplied __GFP_NO_OBJ_EXT:
> 
> 	if (gfp & __GFP_NO_OBJ_EXT)
> 		return NULL;
> 
> Moving this filtering to the caller would let the oversized prefill path
> avoid losing __GFP_NOFAIL.But I would keep the SLAB_KMALLOC-specific
> __GFP_NO_OBJ_EXT allocation and the matching free-time mark together.

Sounds good! Thanks!

> Please let me know if you have a better suggestion.
> 
> --
> With Best Regards,
> Shengming