Re: [PATCH] slab: Remove slab_folio()

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 9/23/26 22:41, Matthew Wilcox wrote:
> On Wed, Sep 23, 2026 at 10:11:06PM +0200, Vlastimil Babka (SUSE) wrote:
>> On 9/23/26 21:45, Harry Yoo wrote:
>> > With a tiny little nit:
>> > 
>> >> @@ -184,15 +169,16 @@ static inline struct slab *page_slab(const struct page *page)
>> >>   * slab_page - The first struct page allocated for a slab
>> >>   * @s: The slab.
>> >>   *
>> >> - * A convenience wrapper for converting slab to the first struct page of the
>> >> - * underlying folio, to communicate with code not yet converted to folio or
>> >> - * struct slab.
>> >> + * A convenience wrapper for returning the first page allocated to this slab.
>> >> + * to communicate with code not yet converted to struct slab.
>> >     * A convenience wrapper for returning the first "struct" page allocated to this
>> >     * "slab" to communicate with code not yet converted to struct slab.
>> >>   */
>> > 
>> > Perhaps you meant this?
> 
> My eyes are old and don't notice punctuation as well as they used to.
> What I meant was:
> 
>  * A convenience wrapper for returning the first page allocated to this slab.
>  * This is for the benefit of code not yet converted to struct slab.
> 
>> Yeah, and I wonder about the "code not yet converted" part, and if there's
>> anything we can still convert right now. What I can see among slab_page() users:
>> 
>> - slab_order() - we could probably add order (aliasing page's order for now)
>> to struct slab right now and that would be future-proof
> 
> That's trickier than you think because it's stored in the ->flags of
> the second page when PG_head is set.  When divorcing slab and page,
> it moves into struct slab, but we can't do that in advance.

Ah, I see.

>> But:
>> - slab_address() - I guess can only be converted once slab is divorced from
>> page?
> 
> Yeah, it becomes slab->virtual.
> 
>> - __kasan_poison_slab - same as above?
> 
> The loop calling page_kasan_tag_reset() makes me think kasan really
> wants a page here.
> 
>> - several VM_BUG_ON_PAGE() usages - same?
> 
> We could probably introduce a VM_BUG_ON_SLAB if you're interested.

Maybe not worth the effort.

>> - validate_slab_ptr() - same?
> 
> That'll change dramatically -- if we want to validate that a pointer
> really points to a slab object, we'll want to, er, ask if
> virt_to_slab() belongs to the slab slab.
> 
>> __free_slab() - same, obviously
> 
> Right.