From: Giorgi Tchankvetadze <giorgitchankvetadze1997@gmail.com>
To: akpm@linux-foundation.org
Cc: aha310510@gmail.com, david@redhat.com, leitao@debian.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
muchun.song@linux.dev, osalvador@suse.de,
syzbot+417aeb05fd190f3a6da9@syzkaller.appspotmail.com
Subject: Re: [PATCH] mm/hugetlb: add missing hugetlb_lock in __unmap_hugepage_range()
Date: Sat, 23 Aug 2025 12:52:34 +0400 [thread overview]
Message-ID: <1757f780-0228-476c-a5a0-ed980209852d@gmail.com> (raw)
In-Reply-To: <20250822180708.86e79941d7e47e3bb759b193@linux-foundation.org>
+ /*
+ * Check surplus_huge_pages without taking hugetlb_lock.
+ * A race here is okay:
+ * - If surplus goes 0 -> nonzero, we skip restore.
+ * - If surplus goes nonzero -> 0, we also skip.
+ * In both cases we just miss a restore, which is safe.
+ */
+ {
+ unsigned long surplus = READ_ONCE(h->surplus_huge_pages);
+
+ if (!surplus &&
+ __vma_private_lock(vma) &&
+ folio_test_anon(folio) &&
+ READ_ONCE(h->surplus_huge_pages) == surplus) {
+ folio_set_hugetlb_restore_reserve(folio);
+ adjust_reservation = true;
+ }
+ }
spin_unlock(ptl);
On 8/23/2025 5:07 AM, Andrew Morton wrote:
> On Fri, 22 Aug 2025 14:58:57 +0900 Jeongjun Park <aha310510@gmail.com> wrote:
>
>> When restoring a reservation for an anonymous page, we need to check to > freeing a surplus. However, __unmap_hugepage_range() causes data
> race > because it reads h->surplus_huge_pages without the protection of
> > hugetlb_lock. > > Therefore, we need to add missing hugetlb_lock. >
> > ... > > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -5951,6 +5951,8
> @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct
> vm_area_struct *vma, > * If there we are freeing a surplus, do not set
> the restore > * reservation bit. > */ > + spin_lock_irq(&hugetlb_lock);
> > + > if (!h->surplus_huge_pages && __vma_private_lock(vma) && >
> folio_test_anon(folio)) { > folio_set_hugetlb_restore_reserve(folio); >
> @@ -5958,6 +5960,7 @@ void __unmap_hugepage_range(struct mmu_gather
> *tlb, struct vm_area_struct *vma, > adjust_reservation = true; > } > > +
> spin_unlock_irq(&hugetlb_lock); > spin_unlock(ptl); >
> Does hugetlb_lock nest inside page_table_lock?
>
> It's a bit sad to be taking a global lock just to defend against some
> alleged data race which probably never happens. Doing it once per
> hugepage probably won't matter but still, is there something more
> proportionate that we can do here?
>
next prev parent reply other threads:[~2025-08-23 8:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 5:58 [PATCH] mm/hugetlb: add missing hugetlb_lock in __unmap_hugepage_range() Jeongjun Park
2025-08-22 15:19 ` Sidhartha Kumar
2025-08-23 1:07 ` Andrew Morton
2025-08-23 8:52 ` Giorgi Tchankvetadze [this message]
2025-08-23 14:40 ` Jeongjun Park
2025-08-23 15:07 ` Jeongjun Park
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=1757f780-0228-476c-a5a0-ed980209852d@gmail.com \
--to=giorgitchankvetadze1997@gmail.com \
--cc=aha310510@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=syzbot+417aeb05fd190f3a6da9@syzkaller.appspotmail.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;
as well as URLs for NNTP newsgroup(s).