From: Mark Brown <broonie@kernel.org>
To: Jann Horn <jannh@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
linux-mm@kvack.org, Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Aishwarya.TCV@arm.com, Naresh Kamboju <naresh.kamboju@linaro.org>
Subject: Re: [PATCH] hugetlb: block hugetlb file creation if hugetlb is not set up
Date: Mon, 16 Jun 2025 23:09:36 +0100 [thread overview]
Message-ID: <5777f917-fe36-4e78-8a10-913c9241816d@sirena.org.uk> (raw)
In-Reply-To: <CAG48ez0fQ5Ukg=0Scsv=N2k2jS=YRQpxLFeQRwMREABUr6yrgQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5103 bytes --]
On Tue, Jun 03, 2025 at 06:29:24AM +0200, Jann Horn wrote:
> On Tue, Jun 3, 2025 at 5:41 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Wed, 28 May 2025 19:51:29 +0200 Jann Horn <jannh@google.com> wrote:
> > > Lock it down by completely denying creation of hugetlb files if no huge
> > > pages for the hstate could be allocated without administratively
> > > changing huge page limits.
> > So this is a non-backward-compatible change?
> Yes, this change changes kernel behavior that is userspace-visible,
> and causes syscalls to return errors where they worked before.
> > If any userspace is affected it's probably either stupid or evil, but I
> > do wonder if there are legit cases for doing this, such as "I don't
> > know if there are any hugepages configured, but I'll try this anyway
> > and figure out what to do later on". And maybe there are other legit
> > cases!
> Right. I think an affected case would be if userspace tries to detect
> whether the kernel supports hugepages by creating a MAP_NORESERVE
> mapping or huge memfd, and if that works, twiddles sysfs knobs to
This does indeed cause at least the LTP memfd_create04 testcase to fall
over on systems with less memory, if it finds hugepages information in
/sys it explicitly creates a MFD_HUGETLB memfd at various sizes and then
just closes them without verifying that there are any actual pages at
any of the supported sizes. I don't think this is a particular problem,
it's pure test code rather than an actual use case, but seems worth
highlighting and people will notice LTP issues if this gets backported
to stable. It seems reasonable to update LTP here (probably with better
hugepages enumeration code?).
tst_test.c:1900: TINFO: LTP version: 20250130-1-g60fe84aaf
tst_test.c:1904: TINFO: Tested kernel: 6.16.0-rc2-next-20250616 #1 SMP PREEMPT Mon Jun 16 07:16:11 UTC 2025 aarch64
tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
tst_test.c:1722: TINFO: Overall timeout per run is 0h 01m 30s
memfd_create04.c:66: TINFO: Attempt to create file using 64kB huge page size
memfd_create04.c:75: TFAIL: memfd_create() failed unexpectedly: ENOMEM (12)
The mm selftests might also be impacted here, some of them do a similar
check for supported huge page sizes by looking in /proc without checking
if there's any actual pages available. I should resurrect the thread
where I asked about that. Our CI only runs the mm selftests with
hugepages explicitly configured so wouldn't notice.
bisect log FWIW:
git bisect start
# status: waiting for both good and bad commits
# bad: [050f8ad7b58d9079455af171ac279c4b9b828c11] Add linux-next specific files for 20250616
git bisect bad 050f8ad7b58d9079455af171ac279c4b9b828c11
# status: waiting for good commit(s), bad commit known
# good: [d39a02e47d1e0fba70992a45ec6a6591268a11a8] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect good d39a02e47d1e0fba70992a45ec6a6591268a11a8
# bad: [852f31106c2bd9d7ca17ab766fcaf6ac5a96f037] Merge branch 'for-linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
git bisect bad 852f31106c2bd9d7ca17ab766fcaf6ac5a96f037
# bad: [c9b6136d8ef32de2441225e47dfa7b32342fb67b] Merge branch 'xtensa-for-next' of git://github.com/jcmvbkbc/linux-xtensa.git
git bisect bad c9b6136d8ef32de2441225e47dfa7b32342fb67b
# bad: [496dd87c6e8bdad67563009b6793c59178b117fa] Merge branch 'next' of https://github.com/Broadcom/stblinux.git
git bisect bad 496dd87c6e8bdad67563009b6793c59178b117fa
# bad: [5091252d7c0bb144d359fbfb5838adcea29f5601] Merge branch 'mm-nonmm-unstable' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect bad 5091252d7c0bb144d359fbfb5838adcea29f5601
# bad: [3e546482aa3d3a3bb0ee9bbaaaa396d7d57a2b63] drivers,cxl: use node-notifier instead of memory-notifier
git bisect bad 3e546482aa3d3a3bb0ee9bbaaaa396d7d57a2b63
# bad: [e5437627e74d7f610a296c215fc557e6b5436610] mm: rename CONFIG_PAGE_BLOCK_ORDER to CONFIG_PAGE_BLOCK_MAX_ORDER
git bisect bad e5437627e74d7f610a296c215fc557e6b5436610
# good: [c03ff8cc73ddad14444dde3384c34d3d4dfbc354] mm: ksm: have KSM VMA checks not require a VMA pointer
git bisect good c03ff8cc73ddad14444dde3384c34d3d4dfbc354
# bad: [1b8405a9525fafb31b0feb38e1be73aefaee9ce0] mm: Kconfig: use verb *use* in plural form in description
git bisect bad 1b8405a9525fafb31b0feb38e1be73aefaee9ce0
# good: [42da1e1d4762be8d70db9d8cefea7cd0fb6e3d15] mm/hugetlb: convert hugetlb_change_protection() to folios
git bisect good 42da1e1d4762be8d70db9d8cefea7cd0fb6e3d15
# bad: [326969ed54efc372555acbf726a28ce537c43525] mm/vmstat: make MEMCG select VM_EVENT_COUNTERS
git bisect bad 326969ed54efc372555acbf726a28ce537c43525
# bad: [3b0376d70ab0de716559b10fa8211743c9288529] hugetlb: block hugetlb file creation if hugetlb is not set up
git bisect bad 3b0376d70ab0de716559b10fa8211743c9288529
# first bad commit: [3b0376d70ab0de716559b10fa8211743c9288529] hugetlb: block hugetlb file creation if hugetlb is not set up
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-06-16 22:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 17:51 Jann Horn
2025-06-03 3:41 ` Andrew Morton
2025-06-03 4:29 ` Jann Horn
2025-06-03 5:43 ` Oscar Salvador
2025-06-03 19:14 ` Jann Horn
2025-06-04 2:54 ` Andrew Morton
2025-06-16 22:09 ` Mark Brown [this message]
2025-06-17 9:13 ` David Hildenbrand
2025-06-17 15:35 ` Jann Horn
2025-06-17 8:12 ` kernel test robot
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=5777f917-fe36-4e78-8a10-913c9241816d@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Aishwarya.TCV@arm.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=muchun.song@linux.dev \
--cc=naresh.kamboju@linaro.org \
--cc=osalvador@suse.de \
/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