From: Karl Mehltretter <kmehltretter@gmail.com>
To: Ackerley Tng <ackerleytng@google.com>
Cc: Karl Mehltretter <kmehltretter@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Jinmeng Zhou <zhoujinmeng@bytedance.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>, Peter Xu <peterx@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3 2/4] mm: hugetlb: Fix out_put_pages subpool reserve calculation
Date: Sun, 27 Sep 2026 19:01:03 +0200 [thread overview]
Message-ID: <20260927170103.2381-1-kmehltretter@gmail.com> (raw)
In-Reply-To: <20260916-hugetlb-subpool-always-track-used-v3-2-38aae9b5ccdd@google.com>
On Wed, 16 Sep 2026 16:39:02 -0700, Ackerley Tng wrote:
> +out_put_pages:
> + gbl_resv_put = hugepage_subpool_put_pages(spool, chg);
> + /*
> + * There may be a difference between the number of
> + * reservations to consume and the number to restore now if
> + * there are multiple threads interacting with the subpool -
> + * restore the difference.
> + */
> + hugetlb_acct_memory(h, gbl_resv_get - gbl_resv_put);
I was able to turn this positive adjustment into a deterministic runtime
failure.
hugetlb_acct_memory() can fail with -ENOMEM, but the subpool's local
state has already been restored and the return value is ignored.
I tested the exact patch prefixes on v7.3-rc3 in x86-64 QEMU with 2 MiB
huge pages, at both one and four vCPUs. A default-off test hook enforced
this ordering:
1. A four-page reservation consumes the two remaining minimum reservations
of a min_size=8M mount and needs two more globally.
2. Global accounting fails because another mount has filled the global
pool.
3. Before rollback, two existing reservations are released and a competing
reservation consumes that newly available capacity.
4. The complete subpool put restores the local four-page minimum, but the
required +2 global correction fails with -ENOMEM.
Both CPU counts produced the same result:
Source state Cleanup result After file removal / after unmount
------------ -------------- ---------------------------------
v7.3-rc3 old cleanup 4 / 0
patch 1 old local leak 2 / 2
patches 1-2 +2, -ENOMEM 2 / ULONG_MAX-1
patches 1-4 +2, -ENOMEM 2 / ULONG_MAX-1
The expected values are 4 after file removal and 0 after unmount. The
ULONG_MAX-1 value is the resulting HugePages_Rsvd underflow.
So, although the unchecked positive call is an older pattern, this
controlled interleaving is balanced on the rc3 base. Patch 1 makes it
reachable on the minimum-only mount, and patch 2 changes patch 1's local
leak into globally unbacked subpool reservations.
This confirms that checking the return value only after the put would be
too late. I think the get has to remain provisional until global accounting
either commits or aborts, so rollback cannot expose capacity and then need
to reacquire it.
A LLM agent helped me with the tests.
Thanks,
Karl
next prev parent reply other threads:[~2026-09-27 17:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 23:39 [PATCH v3 0/4] Fix HugeTLB subpool used_hpages tracking Ackerley Tng
2026-09-16 23:39 ` Ackerley Tng via B4 Relay
2026-09-16 23:39 ` [PATCH v3 1/4] mm: hugetlb: Track used_hpages when getting/putting pages from subpool Ackerley Tng
2026-09-16 23:39 ` Ackerley Tng via B4 Relay
2026-09-16 23:39 ` [PATCH v3 2/4] mm: hugetlb: Fix out_put_pages subpool reserve calculation Ackerley Tng
2026-09-16 23:39 ` Ackerley Tng via B4 Relay
2026-09-27 17:01 ` Karl Mehltretter [this message]
2026-09-16 23:39 ` [PATCH v3 3/4] mm: hugetlb: Fix subpool usage leak on allocation failure Ackerley Tng
2026-09-16 23:39 ` Ackerley Tng via B4 Relay
2026-09-27 17:04 ` Karl Mehltretter
2026-09-28 5:19 ` Ackerley Tng
2026-09-28 6:28 ` Karl Mehltretter
2026-09-16 23:39 ` [PATCH v3 4/4] mm: hugetlb: Avoid re-allocating global reservations on region add failure Ackerley Tng
2026-09-16 23:39 ` Ackerley Tng via B4 Relay
2026-09-17 19:26 ` Joshua Hahn
2026-09-18 3:13 ` Ackerley Tng
2026-09-17 3:13 ` [PATCH v3 0/4] Fix HugeTLB subpool used_hpages tracking Andrew Morton
2026-09-17 19:29 ` Joshua Hahn
2026-09-18 3:05 ` Ackerley Tng
2026-09-18 3:53 ` Andrew Morton
2026-09-18 3:21 ` Ackerley Tng
2026-09-23 22:09 ` Karl Mehltretter
2026-09-24 0:27 ` Ackerley Tng
2026-09-26 22:42 ` Ackerley Tng
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=20260927170103.2381-1-kmehltretter@gmail.com \
--to=kmehltretter@gmail.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=stable@vger.kernel.org \
--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 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.