[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFupdJ_ky4wT6wGM@localhost.localdomain>
Date: Wed, 25 Jun 2025 09:47:00 +0200
From: Oscar Salvador <osalvador@...e.de>
To: David Hildenbrand <david@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Muchun Song <muchun.song@...ux.dev>, Peter Xu <peterx@...hat.com>,
Gavin Guo <gavinguo@...lia.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/5] mm,hugetlb: Sort out folio locking in the
faulting path
On Mon, Jun 23, 2025 at 04:11:38PM +0200, David Hildenbrand wrote:
> > @@ -6801,13 +6810,24 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> > /* Fallthrough to CoW */
> > }
> > - /* hugetlb_wp() requires page locks of pte_page(vmf.orig_pte) */
> > - folio = page_folio(pte_page(vmf.orig_pte));
> > - folio_lock(folio);
> > - folio_get(folio);
> > -
> > if (flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) {
> > if (!huge_pte_write(vmf.orig_pte)) {
> > + /*
> > + * Anonymous folios need to be lock since hugetlb_wp()
> > + * checks whether we can re-use the folio exclusively
> > + * for us in case we are the only user of it.
> > + */
>
> Should we move that comment to hugetlb_wp() instead? And if we are already
> doing this PTL unlock dance now, why not do it in hugetlb_wp() instead so we
> can simplify this code?
Yes, probably we can move it further up.
Let me see how it would look.
thanks!
--
Oscar Salvador
SUSE Labs
Powered by blists - more mailing lists