From: Vlastimil Babka <vbabka@suse.cz>
To: Matthew Wilcox <willy@infradead.org>, linux-mm@kvack.org
Cc: Harry Yoo <harry.yoo@oracle.com>,
David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: [PATCH RFC] mm, slab: warn when increasing refcount on large kmalloc page
Date: Thu, 17 Apr 2025 09:41:03 +0200 [thread overview]
Message-ID: <20250417074102.4543-2-vbabka@suse.cz> (raw)
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
next reply other threads:[~2025-04-17 7:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 7:41 Vlastimil Babka [this message]
2025-04-18 14:04 ` Harry Yoo
2025-04-20 2:41 ` David Rientjes
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=20250417074102.4543-2-vbabka@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=harry.yoo@oracle.com \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox