From: Peter Xu <peterx@redhat.com>
To: James Houghton <jthoughton@google.com>
Cc: Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@redhat.com>,
Gavin Guo <gavinguo@igalia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
muchun.song@linux.dev, akpm@linux-foundation.org,
mike.kravetz@oracle.com, kernel-dev@igalia.com,
stable@vger.kernel.org, Hugh Dickins <hughd@google.com>,
Florent Revest <revest@google.com>, Gavin Shan <gshan@redhat.com>
Subject: Re: [PATCH v3] mm/hugetlb: fix a deadlock with pagecache_folio and hugetlb_fault_mutex_table
Date: Wed, 28 May 2025 12:24:24 -0400 [thread overview]
Message-ID: <aDc4uO_Vq-q7ks5h@x1.local> (raw)
In-Reply-To: <CADrL8HXD0hX+5WvtZWKXAr0NvfvOJZhqL9PVBawYQuAyzhGgYg@mail.gmail.com>
On Wed, May 28, 2025 at 12:14:28PM -0400, James Houghton wrote:
[...]
> > > For 2) I am also not sure if we need need the pagecache folio locked; I
> > > doubt it ... but this code is not the easiest to follow.
> >
> > I have been staring at that code and thinking about potential scenarios
> > for a few days now, and I cannot convice myself that we need
> > pagecache_folio's lock when pagecache_folio != old_folio because as a
> > matter of fact I cannot think of anything it protects us against.
>
> Hi Oscar,
Hey, James,
>
> Have you thought about the UFFDIO_CONTINUE case (hugetlb_mfill_atomic_pte())?
>
> I'm slightly concerned that, if you aren't holding pagecache_folio's
> lock, there might be issues where hugetlb_mfill_atomic_pte() proceeds
> to map a hugetlb page that it is not supposed to. (For example, if the
> fault handler does not generally hold pagecache_folio's lock,
> hugetlb_mfill_atomic_pte() will see a page in the pagecache and map
> it, even though it may not have been zeroed yet.)
>
> I haven't had enough time to fully think through this case, but just
> want to make sure it has been considered.
AFAIU we're talking about two separate code paths. IIUC you're talking
about a fresh new hugetlb folio being allocated, but then that's what
hugetlb_no_page() does. Folio lock required there.
Here IIUC Oscar's context is only in hugetlb_wp() where there's a niche use
case to compare whether a VM_PRIVATE has already CoWed once from a
pagecache, and whether we need the folio lock for the pagecache lookup.
Aka, this one:
if ((flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) &&
!(vma->vm_flags & VM_MAYSHARE) && !huge_pte_write(vmf.orig_pte)) {
if (vma_needs_reservation(h, vma, vmf.address) < 0) {
ret = VM_FAULT_OOM;
goto out_mutex;
}
/* Just decrements count, does not deallocate */
vma_end_reservation(h, vma, vmf.address);
pagecache_folio = filemap_lock_hugetlb_folio(h, mapping, <---
vmf.pgoff);
if (IS_ERR(pagecache_folio))
pagecache_folio = NULL;
}
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2025-05-28 16:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 2:33 Gavin Guo
2025-05-28 9:27 ` Oscar Salvador
2025-05-28 15:03 ` Peter Xu
2025-05-28 15:09 ` David Hildenbrand
2025-05-28 15:45 ` Oscar Salvador
2025-05-28 16:14 ` James Houghton
2025-05-28 16:24 ` Peter Xu [this message]
2025-05-28 16:16 ` Peter Xu
2025-05-28 20:00 ` David Hildenbrand
2025-05-28 20:26 ` David Hildenbrand
2025-05-28 21:34 ` Oscar Salvador
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=aDc4uO_Vq-q7ks5h@x1.local \
--to=peterx@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gavinguo@igalia.com \
--cc=gshan@redhat.com \
--cc=hughd@google.com \
--cc=jthoughton@google.com \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=revest@google.com \
--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