Re: [PATCH RFC] mm, slab: warn when increasing refcount on large kmalloc page

[Harry Yoo <harry.yoo@oracle.com>]

On Thu, Apr 17, 2025 at 09:41:03AM +0200, Vlastimil Babka wrote:
> Since slab pages are now frozen, increasing refcount on a page
> containing a kmalloc() allocation is not possible anymore. Large kmalloc
> pages should ideally behave the same, because the decision for which
> allocation size to use them is the slab allocator's implementation
> detail, and sizes passed to kmalloc() might depend on e.g. user input.

Agreed.

> Because of some unexpected fallout in the slab pages case (see commit
> b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page"),
> let's take a more cautious approach and before making large kmalloc
> pages actually frozen, start warning about code that would try to
> increase refcount on them.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> I'd like to expose this via slab-next and see if there are any reports.
> If not for few weeks, maybe proceed immediately to freezing refcount and
> handling it in get_page/put_page exactly like folio_test_slab. Thoughts?

+1

Let's give testing a try.

...at least it does not hit anything on my box.

-- 
Cheers,
Harry / Hyeonggon

>  include/linux/mm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b7f13f087954..664c67346484 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1532,6 +1532,7 @@ static inline void get_page(struct page *page)
>  	struct folio *folio = page_folio(page);
>  	if (WARN_ON_ONCE(folio_test_slab(folio)))
>  		return;
> +	WARN_ON_ONCE(folio_test_large_kmalloc(folio));
>  	folio_get(folio);
>  }
>  
> -- 
> 2.49.0