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

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

[Vlastimil Babka]

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.

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?

 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

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

[Harry Yoo]

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

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

[David Rientjes]

On Fri, 18 Apr 2025, Harry Yoo 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.
> 

Same, I ran this through a number of benchmarks on x86 and couldn't find 
any occurrences of the warning.

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

[David Rientjes]

On Sat, 19 Apr 2025, David Rientjes 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.
> > 
> 
> Same, I ran this through a number of benchmarks on x86 and couldn't find 
> any occurrences of the warning.
> 

Btw, the benchmarks that I normally run regularly on SLUB are kernbench, 
multichase, hackbench, specjbb, will-it-scale, redis, unixbench, netperf 
TCP_RR and UDP_STREAM, on both x86 and arm64.  I haven't run on any other 
architectures recently, but perhaps others do.

Are there any other benchmarks that people normally run for slab allocator 
related changes?

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

[Matthew Wilcox]

On Thu, Apr 17, 2025 at 09:41:03AM +0200, Vlastimil Babka wrote:
> 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?

I think you're being too cautious ;-)  I had a bit of a play around to
see if there's a way of getting gcc to optimise the generated code for
this, but didn't come up with anything too clever.