From: Karl Mehltretter <kmehltretter@gmail.com>
To: Zhao Li <enderaoelyther@gmail.com>
Cc: Karl Mehltretter <kmehltretter@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Ma Wupeng <mawupeng1@huawei.com>,
Jinmeng Zhou <zhoujinmeng@bytedance.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm/hugetlb: fix max-only subpool accounting on alloc_hugetlb_folio failure
Date: Wed, 23 Sep 2026 08:57:14 +0200 [thread overview]
Message-ID: <20260923065714.20781-1-kmehltretter@gmail.com> (raw)
In-Reply-To: <20260428113037.88766-2-enderaoelyther@gmail.com>
On Tue, Apr 28, 2026, Zhao Li wrote:
> Mounts with min_hpages != -1 are left unchanged for now.
In case it helps with that follow-up, here is a small reproducer for the
min_size case. It needs no hugetlb cgroup.
The pool has two huge pages and no overcommit, and the mount is
size=8M,min_size=4M. A test maps a 4-page file MAP_SHARED | MAP_NORESERVE,
touches the first N pages, then unmaps and removes the file. Five rounds
on one mount:
N faults ok / SIGBUS statfs free / blocks HugePages_Rsvd
- 2 (after mount)
2 2 / 0 4 / 4 2
2 2 / 0 4 / 4 2
4 2 / 2 2 / 4 0
2 2 / 0 2 / 4 0
2 2 / 0 2 / 4 0
The two SIGBUS faults keep their used_hpages charge. Half of the quota
stays gone with no file on the mount. used_hpages then no longer drops
below min_hpages, so hugepage_subpool_put_pages() never restores
rsv_hpages, and the mount has lost its minimum reservation for good.
The out_subpool_put: path skips this case on purpose, as the commit
message says.
Same result on v7.3-rc4 (f0100363d8c3), on v7.3-rc4 with this patch, and
on next-20260922. That tree also has 6f8b22e85eac ("mm/hugetlb: fix subpool
minimum reservation rollback"), which fixes the hugetlb_reserve_pages()
error path. This is the fault path. Tested under QEMU x86_64, one CPU.
Thanks,
Karl
#include <fcntl.h>
#include <setjmp.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/statfs.h>
#include <unistd.h>
#define HPAGE (2UL << 20)
static sigjmp_buf env;
static void on_sigbus(int sig)
{
siglongjmp(env, 1);
}
/* usage: t <hugetlbfs dir> <pages to touch, at most 4> */
int main(int argc, char **argv)
{
int n = atoi(argv[2]), fd, i;
volatile int ok = 0, bus = 0;
struct statfs st;
char path[256];
char *p;
signal(SIGBUS, on_sigbus);
snprintf(path, sizeof(path), "%s/f", argv[1]);
fd = open(path, O_CREAT | O_RDWR, 0600);
if (fd < 0 || ftruncate(fd, 4 * HPAGE))
return 1;
p = mmap(NULL, 4 * HPAGE, PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_NORESERVE, fd, 0);
if (p == MAP_FAILED)
return 1;
for (i = 0; i < n; i++) {
if (!sigsetjmp(env, 1)) {
p[i * HPAGE] = 1;
ok++;
} else {
bus++;
}
}
munmap(p, 4 * HPAGE);
close(fd);
unlink(path);
statfs(argv[1], &st);
printf("ok=%d sigbus=%d free=%ld/%ld\n", ok, bus,
(long)st.f_bfree, (long)st.f_blocks);
return 0;
}
echo 0 > /proc/sys/vm/nr_overcommit_hugepages
echo 2 > /proc/sys/vm/nr_hugepages
mount -t hugetlbfs -o size=8M,min_size=4M none /mnt/h
for n in 2 2 4 2 2; do ./t /mnt/h $n; grep HugePages_Rsvd /proc/meminfo; done
prev parent reply other threads:[~2026-09-23 6:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 14:52 [PATCH] mm/hugetlb: fix subpool accounting after cgroup charge failure Catherine
2026-04-27 15:12 ` Andrew Morton
2026-04-27 15:19 ` Catherine
2026-04-27 21:12 ` Andrew Morton
2026-04-28 3:07 ` [PATCH v2] " Zhao Li
2026-04-28 9:08 ` Oscar Salvador
2026-04-28 11:30 ` Lance Yang
2026-04-28 11:41 ` Zhao Li
2026-04-28 11:41 ` Zhao Li
2026-04-28 11:30 ` [PATCH v3] mm/hugetlb: fix max-only subpool accounting on alloc_hugetlb_folio failure Zhao Li
2026-09-06 2:31 ` Andrew Morton
2026-09-08 7:12 ` Zhao Li
2026-09-23 6:57 ` Karl Mehltretter [this message]
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=20260923065714.20781-1-kmehltretter@gmail.com \
--to=kmehltretter@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=enderaoelyther@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mawupeng1@huawei.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=zhoujinmeng@bytedance.com \
/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
all inboxes | Powered by JetHome®