From: Andrew Morton <akpm@linux-foundation.org>
To: ackerleytng@google.com
Cc: Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org>,
Alex Shi <alexs@kernel.org>, David Hildenbrand <david@kernel.org>,
Dongliang Mu <dzm91@hust.edu.cn>,
Hongxiang Lou <louhongxiang@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Jonathan Corbet <corbet@lwn.net>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
"Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Miaohe Lin <linmiaohe@huawei.com>,
Michal Hocko <mhocko@kernel.org>, Mike Rapoport <rppt@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
Nhat Pham <nphamcs@gmail.com>, Oscar Salvador <osalvador@suse.de>,
Peter Xu <peterx@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Shuah Khan <skhan@linuxfoundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Usama Arif <usama.arif@linux.dev>,
Vlastimil Babka <vbabka@kernel.org>,
Wupeng Ma <mawupeng1@huawei.com>,
Yanteng Si <si.yanteng@linux.dev>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
fvdl@google.com, jthoughton@google.com, rientjes@google.com,
vannapurve@google.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3 0/4] Fix HugeTLB subpool used_hpages tracking
Date: Wed, 16 Sep 2026 20:13:07 -0700 [thread overview]
Message-ID: <20260916201307.5618114cbac4af52d98aecfa@linux-foundation.org> (raw)
In-Reply-To: <20260916-hugetlb-subpool-always-track-used-v3-0-38aae9b5ccdd@google.com>
On Wed, 16 Sep 2026 16:39:00 -0700 Ackerley Tng via B4 Relay <devnull+ackerleytng.google.com@kernel.org> wrote:
> HugeTLB subpools currently only track used pages (used_hpages) when a
> maximum size limit (max_hpages) is configured on the mount.
>
> ...
>
> This series addresses three problem areas resulting from untracked usage
> and asymmetric error handling:
These are rather serious-sounding problems.
I'm seeing Fixes: for 10-year-old patches, for one last year and one
this year. The fourth patch doesn't identify what to fix.
So if downstream people (-stable maintainers, others) follow our
recommendations, some kernels will get two of these patches, other
kernel versions will get three and some lucky kernels might get all
four. Are you confident that the patches can be split apart in this
fashion and still produce a good result? After all, we're sending
downstream some patch combinations which we didn't test.
Also, can you speculate about why these things took so long to
discover?
Ho hum, complicated. Let's at least slap a Fixes: on [4/4]. My
trillion-dollar sidekick suggests a9e443086489 ("hugetlb: disable
region_add file_region coalescing").
Our other little friend is talking to us:
https://sashiko.dev/#/patchset/20260916-hugetlb-subpool-always-track-used-v3-0-38aae9b5ccdd@google.com
I'd like to queue this up promptly because it fixes things. But let's
seek additional review input and argue with Sashiko before taking that
step.
next prev parent reply other threads:[~2026-09-17 3:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 via B4 Relay
2026-09-16 23:39 ` [PATCH v3 2/4] mm: hugetlb: Fix out_put_pages subpool reserve calculation Ackerley Tng via B4 Relay
2026-09-16 23:39 ` [PATCH v3 3/4] mm: hugetlb: Fix subpool usage leak on allocation failure Ackerley Tng via B4 Relay
2026-09-16 23:39 ` [PATCH v3 4/4] mm: hugetlb: Avoid re-allocating global reservations on region add failure Ackerley Tng via B4 Relay
2026-09-17 19:26 ` Joshua Hahn
2026-09-18 3:13 ` Ackerley Tng
2026-09-17 3:13 ` Andrew Morton [this message]
2026-09-17 19:29 ` [PATCH v3 0/4] Fix HugeTLB subpool used_hpages tracking Joshua Hahn
2026-09-18 3:05 ` Ackerley Tng
2026-09-18 3:53 ` Andrew Morton
2026-09-18 3:21 ` 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=20260916201307.5618114cbac4af52d98aecfa@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ackerleytng@google.com \
--cc=alexs@kernel.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=devnull+ackerleytng.google.com@kernel.org \
--cc=dzm91@hust.edu.cn \
--cc=fvdl@google.com \
--cc=hannes@cmpxchg.org \
--cc=joshua.hahnjy@gmail.com \
--cc=jthoughton@google.com \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=louhongxiang@huawei.com \
--cc=mawupeng1@huawei.com \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=nphamcs@gmail.com \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=si.yanteng@linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vannapurve@google.com \
--cc=vbabka@kernel.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
all inboxes | Powered by JetHome®