From: Oscar Salvador <osalvador@suse.de>
To: Peter Xu <peterx@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Breno Leitao <leitao@debian.org>, Rik van Riel <riel@surriel.com>,
Muchun Song <muchun.song@linux.dev>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Ackerley Tng <ackerleytng@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-stable <stable@vger.kernel.org>
Subject: Re: [PATCH v2 1/7] mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool
Date: Mon, 13 Jan 2025 12:02:26 +0100 [thread overview]
Message-ID: <Z4Tywpu-JpIRwh2G@localhost.localdomain> (raw)
In-Reply-To: <20250107204002.2683356-2-peterx@redhat.com>
On Tue, Jan 07, 2025 at 03:39:56PM -0500, Peter Xu wrote:
> Since commit 04f2cbe35699 ("hugetlb: guarantee that COW faults for a
> process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed"),
> avoid_reserve was introduced for a special case of CoW on hugetlb private
> mappings, and only if the owner VMA is trying to allocate yet another
> hugetlb folio that is not reserved within the private vma reserved map.
>
> Later on, in commit d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle areas
> hole punched by fallocate"), alloc_huge_page() enforced to not consume any
> global reservation as long as avoid_reserve=true. This operation doesn't
> look correct, because even if it will enforce the allocation to not use
> global reservation at all, it will still try to take one reservation from
> the spool (if the subpool existed). Then since the spool reserved pages
> take from global reservation, it'll also take one reservation globally.
>
> Logically it can cause global reservation to go wrong.
>
> I wrote a reproducer below, trigger this special path, and every run of
> such program will cause global reservation count to increment by one, until
> it hits the number of free pages:
>
> #define _GNU_SOURCE /* See feature_test_macros(7) */
> #include <stdio.h>
> #include <fcntl.h>
> #include <errno.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <sys/mman.h>
>
> #define MSIZE (2UL << 20)
>
> int main(int argc, char *argv[])
> {
> const char *path;
> int *buf;
> int fd, ret;
> pid_t child;
>
> if (argc < 2) {
> printf("usage: %s <hugetlb_file>\n", argv[0]);
> return -1;
> }
>
> path = argv[1];
>
> fd = open(path, O_RDWR | O_CREAT, 0666);
> if (fd < 0) {
> perror("open failed");
> return -1;
> }
>
> ret = fallocate(fd, 0, 0, MSIZE);
> if (ret != 0) {
> perror("fallocate");
> return -1;
> }
>
> buf = mmap(NULL, MSIZE, PROT_READ|PROT_WRITE,
> MAP_PRIVATE, fd, 0);
>
> if (buf == MAP_FAILED) {
> perror("mmap() failed");
> return -1;
> }
>
> /* Allocate a page */
> *buf = 1;
>
> child = fork();
> if (child == 0) {
> /* child doesn't need to do anything */
> exit(0);
> }
>
> /* Trigger CoW from owner */
> *buf = 2;
>
> munmap(buf, MSIZE);
> close(fd);
> unlink(path);
>
> return 0;
> }
>
> It can only reproduce with a sub-mount when there're reserved pages on the
> spool, like:
>
> # sysctl vm.nr_hugepages=128
> # mkdir ./hugetlb-pool
> # mount -t hugetlbfs -o min_size=8M,pagesize=2M none ./hugetlb-pool
>
> Then run the reproducer on the mountpoint:
>
> # ./reproducer ./hugetlb-pool/test
>
> Fix it by taking the reservation from spool if available. In general,
> avoid_reserve is IMHO more about "avoid vma resv map", not spool's.
>
> I copied stable, however I have no intention for backporting if it's not a
> clean cherry-pick, because private hugetlb mapping, and then fork() on top
> is too rare to hit.
>
> Cc: linux-stable <stable@vger.kernel.org>
> Fixes: d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate")
> Reviewed-by: Ackerley Tng <ackerleytng@google.com>
> Tested-by: Ackerley Tng <ackerleytng@google.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2025-01-13 11:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 20:39 [PATCH v2 0/7] mm/hugetlb: Refactor hugetlb allocation resv accounting Peter Xu
2025-01-07 20:39 ` [PATCH v2 1/7] mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool Peter Xu
2025-01-13 11:02 ` Oscar Salvador [this message]
2025-01-07 20:39 ` [PATCH v2 2/7] mm/hugetlb: Stop using avoid_reserve flag in fork() Peter Xu
2025-01-13 11:05 ` Oscar Salvador
2025-01-07 20:39 ` [PATCH v2 3/7] mm/hugetlb: Rename avoid_reserve to cow_from_owner Peter Xu
2025-01-13 11:20 ` Oscar Salvador
2025-01-13 16:19 ` Peter Xu
2025-01-16 10:15 ` Oscar Salvador
2025-01-16 14:26 ` Peter Xu
2025-01-07 20:39 ` [PATCH v2 4/7] mm/hugetlb: Clean up map/global resv accounting when allocate Peter Xu
2025-01-13 22:57 ` Ackerley Tng
2025-01-14 18:25 ` Peter Xu
2025-01-07 20:40 ` [PATCH v2 5/7] mm/hugetlb: Simplify vma_has_reserves() Peter Xu
2025-01-07 20:40 ` [PATCH v2 6/7] mm/hugetlb: Drop vma_has_reserves() Peter Xu
2025-01-07 20:40 ` [PATCH v2 7/7] mm/hugetlb: Unify restore reserve accounting for new allocations Peter Xu
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=Z4Tywpu-JpIRwh2G@localhost.localdomain \
--to=osalvador@suse.de \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=peterx@redhat.com \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
--cc=stable@vger.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