From: Breno Leitao <leitao@debian.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
lstoakes@gmail.com, willy@infradead.org, mike.kravetz@oracle.com,
Rik van Riel <riel@surriel.com>,
"open list:HUGETLB SUBSYSTEM" <linux-mm@kvack.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mm/hugetlb: Restore the reservation if needed
Date: Mon, 29 Jan 2024 04:45:34 -0800 [thread overview]
Message-ID: <Zbed7hlo38WHbQaf@gmail.com> (raw)
In-Reply-To: <7a0d92a9-f28c-4f3c-b956-1157e614dcbe@arm.com>
On Wed, Jan 24, 2024 at 09:22:03AM +0000, Ryan Roberts wrote:
> On 17/01/2024 17:10, Breno Leitao wrote:
> > Currently there is a bug that a huge page could be stolen, and when the
> > original owner tries to fault in it, it causes a page fault.
> >
> > You can achieve that by:
> > 1) Creating a single page
> > echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> >
> > 2) mmap() the page above with MAP_HUGETLB into (void *ptr1).
> > * This will mark the page as reserved
> > 3) touch the page, which causes a page fault and allocates the page
> > * This will move the page out of the free list.
> > * It will also unreserved the page, since there is no more free
> > page
> > 4) madvise(MADV_DONTNEED) the page
> > * This will free the page, but not mark it as reserved.
> > 5) Allocate a secondary page with mmap(MAP_HUGETLB) into (void *ptr2).
> > * it should fail, but, since there is no more available page.
> > * But, since the page above is not reserved, this mmap() succeed.
> > 6) Faulting at ptr1 will cause a SIGBUS
> > * it will try to allocate a huge page, but there is none
> > available
> >
> > A full reproducer is in selftest. See
> > https://lore.kernel.org/all/20240105155419.1939484-1-leitao@debian.org/
> >
> > Fix this by restoring the reserved page if necessary. If the page being
> > unmapped has HPAGE_RESV_OWNER set, and needs a reservation, set the
> > restore_reserve flag, which will move the page from free to reserved.
> >
> > Suggested-by: Rik van Riel <riel@surriel.com>
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > mm/hugetlb.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index ed1581b670d4..fa2c17767e44 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -5677,6 +5677,16 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
> > hugetlb_count_sub(pages_per_huge_page(h), mm);
> > hugetlb_remove_rmap(page_folio(page));
> >
> > + if (is_vma_resv_set(vma, HPAGE_RESV_OWNER) &&
> > + vma_needs_reservation(h, vma, start)) {
> > + /*
> > + * Restore the reservation if needed, otherwise the
> > + * backing page could be stolen by someone.
> > + */
> > + folio_set_hugetlb_restore_reserve(page_folio(page));
> > + vma_add_reservation(h, vma, address);
> > + }
> > +
> > spin_unlock(ptl);
> > tlb_remove_page_size(tlb, page, huge_page_size(h));
> > /*
>
> Hi Breno,
>
> I'm seeing a kernel bug fire when running the "map_hugetlb" mm selftest against latest mm-unstable. Bisect tells me this patch is culprit. I'm running on arm64 with defconfig plus the following:
Hello Ryan,
Thanks for the heads-up. I was able to reproduce the problem, and I am
working on a solution.
Thanks,
prev parent reply other threads:[~2024-01-29 12:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 17:10 Breno Leitao
2024-01-17 17:10 ` [PATCH 2/2] selftests/mm: run_vmtests.sh: add hugetlb_madv_vs_map Breno Leitao
2024-01-24 9:22 ` [PATCH 1/2] mm/hugetlb: Restore the reservation if needed Ryan Roberts
2024-01-29 12:45 ` Breno Leitao [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=Zbed7hlo38WHbQaf@gmail.com \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.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