From: David Rientjes <rientjes@google.com>
To: Harry Yoo <harry.yoo@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH RFC] mm, slab: warn when increasing refcount on large kmalloc page
Date: Sat, 19 Apr 2025 19:41:56 -0700 (PDT) [thread overview]
Message-ID: <8da1a88e-0cbf-fa65-bca9-4843ceb0c8dd@google.com> (raw)
In-Reply-To: <aAJcCczOef1HImMC@harry>
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.
next prev parent reply other threads:[~2025-04-20 2:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 7:41 [PATCH RFC] mm, slab: warn when increasing refcount on large kmalloc page Vlastimil Babka
2025-04-18 14:04 ` Harry Yoo
2025-04-20 2:41 ` David Rientjes [this message]
2025-04-20 2:46 ` David Rientjes
2025-04-23 18:20 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8da1a88e-0cbf-fa65-bca9-4843ceb0c8dd@google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=harry.yoo@oracle.com \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.