* [PATCH v1] mm: centralize+fix comments about compound_mapcount() in new sync_with_folio_pmd_zap()
@ 2026-02-23 16:39 David Hildenbrand (Arm)
2026-02-23 17:58 ` Matthew Wilcox
0 siblings, 1 reply; 3+ messages in thread
From: David Hildenbrand (Arm) @ 2026-02-23 16:39 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mm, David Hildenbrand (Arm),
Andrew Morton, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Rik van Riel,
Harry Yoo, Jann Horn
We still mention compound_mapcount() in two comments.
Instead of simply referring to the folio mapcount in both places, let's
factor out the odd-looking PTL sync into sync_with_folio_pmd_zap(), and
add centralized documentation why this is required.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Harry Yoo <harry.yoo@oracle.com>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
mm/internal.h | 19 +++++++++++++++++++
mm/memory.c | 8 +-------
mm/page_vma_mapped.c | 11 ++---------
3 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index cb0af847d7d9..e0ef192b0be3 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -516,6 +516,25 @@ void free_pgtables(struct mmu_gather *tlb, struct unmap_desc *desc);
void pmd_install(struct mm_struct *mm, pmd_t *pmd, pgtable_t *pte);
+/**
+ * sync_with_folio_pmd_zap - sync with concurrent zapping of a folio PMD
+ * @mm: The mm_struct.
+ * @pmdp: Pointer to the pmd that was found to be pmd_none().
+ *
+ * When we stumble over a pmd_none() without holding the PTL while unmapping a
+ * folio that could have been mapped at that PMD, it could be that concurrent
+ * zapping of the PMD is not complete yet. While the PMD might be pmd_none()
+ * already, the folio might still appear to be mapped (folio_mapped()).
+ *
+ * Wait for concurrent zapping to complete by grabbing the PTL.
+ */
+static inline void sync_with_folio_pmd_zap(struct mm_struct *mm, pmd_t *pmdp)
+{
+ spinlock_t *ptl = pmd_lock(mm, pmdp);
+
+ spin_unlock(ptl);
+}
+
struct zap_details;
void unmap_page_range(struct mmu_gather *tlb,
struct vm_area_struct *vma,
diff --git a/mm/memory.c b/mm/memory.c
index 876bf73959c6..c87d796050ba 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2006,13 +2006,7 @@ static inline unsigned long zap_pmd_range(struct mmu_gather *tlb,
} else if (details && details->single_folio &&
folio_test_pmd_mappable(details->single_folio) &&
next - addr == HPAGE_PMD_SIZE && pmd_none(*pmd)) {
- spinlock_t *ptl = pmd_lock(tlb->mm, pmd);
- /*
- * Take and drop THP pmd lock so that we cannot return
- * prematurely, while zap_huge_pmd() has cleared *pmd,
- * but not yet decremented compound_mapcount().
- */
- spin_unlock(ptl);
+ sync_with_folio_pmd_zap(tlb->mm, pmd);
}
if (pmd_none(*pmd)) {
addr = next;
diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
index b38a1d00c971..a4d52fdb3056 100644
--- a/mm/page_vma_mapped.c
+++ b/mm/page_vma_mapped.c
@@ -269,11 +269,6 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
spin_unlock(pvmw->ptl);
pvmw->ptl = NULL;
} else if (!pmd_present(pmde)) {
- /*
- * If PVMW_SYNC, take and drop THP pmd lock so that we
- * cannot return prematurely, while zap_huge_pmd() has
- * cleared *pmd but not decremented compound_mapcount().
- */
const softleaf_t entry = softleaf_from_pmd(pmde);
if (softleaf_is_device_private(entry)) {
@@ -284,11 +279,9 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
if ((pvmw->flags & PVMW_SYNC) &&
thp_vma_suitable_order(vma, pvmw->address,
PMD_ORDER) &&
- (pvmw->nr_pages >= HPAGE_PMD_NR)) {
- spinlock_t *ptl = pmd_lock(mm, pvmw->pmd);
+ (pvmw->nr_pages >= HPAGE_PMD_NR))
+ sync_with_folio_pmd_zap(mm, pvmw->pmd);
- spin_unlock(ptl);
- }
step_forward(pvmw, PMD_SIZE);
continue;
}
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v1] mm: centralize+fix comments about compound_mapcount() in new sync_with_folio_pmd_zap()
2026-02-23 16:39 [PATCH v1] mm: centralize+fix comments about compound_mapcount() in new sync_with_folio_pmd_zap() David Hildenbrand (Arm)
@ 2026-02-23 17:58 ` Matthew Wilcox
2026-02-23 19:16 ` David Hildenbrand (Arm)
0 siblings, 1 reply; 3+ messages in thread
From: Matthew Wilcox @ 2026-02-23 17:58 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-kernel, linux-mm, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Rik van Riel, Harry Yoo,
Jann Horn
On Mon, Feb 23, 2026 at 05:39:20PM +0100, David Hildenbrand (Arm) wrote:
> void pmd_install(struct mm_struct *mm, pmd_t *pmd, pgtable_t *pte);
>
> +/**
> + * sync_with_folio_pmd_zap - sync with concurrent zapping of a folio PMD
> + * @mm: The mm_struct.
> + * @pmdp: Pointer to the pmd that was found to be pmd_none().
> + *
> + * When we stumble over a pmd_none() without holding the PTL while unmapping a
> + * folio that could have been mapped at that PMD, it could be that concurrent
> + * zapping of the PMD is not complete yet. While the PMD might be pmd_none()
> + * already, the folio might still appear to be mapped (folio_mapped()).
> + *
> + * Wait for concurrent zapping to complete by grabbing the PTL.
> + */
I like this. The one thing we've lost is the name of the function which
does the zapping, which I think was a helpful detail. Perhaps not to
someone who's deep in "how page tables work", but I wouldn't know where
to look for the counterpart to this. So how about:
Option A:
+ * When we stumble over a pmd_none() without holding the PTL while
+ * unmapping a folio that could have been mapped at that PMD,
+ * zap_huge_pmd() may not be complete yet. While the PMD might be pmd_none()
+ * already, the folio might still appear to be mapped (folio_mapped()).
Option B:
+ * When we find a pmd_none() while unmapping a folio without holding
+ * the PTL, zap_huge_pmd() may have cleared the PMD but not yet
+ * modified the folio to indicate that it's unmapped.
(for both options, I'm just changing that one paragraph; the paragraph
starting "Wait", I would leave unchanged)
> +static inline void sync_with_folio_pmd_zap(struct mm_struct *mm, pmd_t *pmdp)
> +{
> + spinlock_t *ptl = pmd_lock(mm, pmdp);
> +
> + spin_unlock(ptl);
> +}
> +
> struct zap_details;
> void unmap_page_range(struct mmu_gather *tlb,
> struct vm_area_struct *vma,
> diff --git a/mm/memory.c b/mm/memory.c
> index 876bf73959c6..c87d796050ba 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2006,13 +2006,7 @@ static inline unsigned long zap_pmd_range(struct mmu_gather *tlb,
> } else if (details && details->single_folio &&
> folio_test_pmd_mappable(details->single_folio) &&
> next - addr == HPAGE_PMD_SIZE && pmd_none(*pmd)) {
> - spinlock_t *ptl = pmd_lock(tlb->mm, pmd);
> - /*
> - * Take and drop THP pmd lock so that we cannot return
> - * prematurely, while zap_huge_pmd() has cleared *pmd,
> - * but not yet decremented compound_mapcount().
> - */
> - spin_unlock(ptl);
> + sync_with_folio_pmd_zap(tlb->mm, pmd);
> }
> if (pmd_none(*pmd)) {
> addr = next;
> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
> index b38a1d00c971..a4d52fdb3056 100644
> --- a/mm/page_vma_mapped.c
> +++ b/mm/page_vma_mapped.c
> @@ -269,11 +269,6 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
> spin_unlock(pvmw->ptl);
> pvmw->ptl = NULL;
> } else if (!pmd_present(pmde)) {
> - /*
> - * If PVMW_SYNC, take and drop THP pmd lock so that we
> - * cannot return prematurely, while zap_huge_pmd() has
> - * cleared *pmd but not decremented compound_mapcount().
> - */
> const softleaf_t entry = softleaf_from_pmd(pmde);
>
> if (softleaf_is_device_private(entry)) {
> @@ -284,11 +279,9 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
> if ((pvmw->flags & PVMW_SYNC) &&
> thp_vma_suitable_order(vma, pvmw->address,
> PMD_ORDER) &&
> - (pvmw->nr_pages >= HPAGE_PMD_NR)) {
> - spinlock_t *ptl = pmd_lock(mm, pvmw->pmd);
> + (pvmw->nr_pages >= HPAGE_PMD_NR))
> + sync_with_folio_pmd_zap(mm, pvmw->pmd);
>
> - spin_unlock(ptl);
> - }
> step_forward(pvmw, PMD_SIZE);
> continue;
> }
> --
> 2.43.0
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v1] mm: centralize+fix comments about compound_mapcount() in new sync_with_folio_pmd_zap()
2026-02-23 17:58 ` Matthew Wilcox
@ 2026-02-23 19:16 ` David Hildenbrand (Arm)
0 siblings, 0 replies; 3+ messages in thread
From: David Hildenbrand (Arm) @ 2026-02-23 19:16 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-kernel, linux-mm, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Rik van Riel, Harry Yoo,
Jann Horn
On 2/23/26 18:58, Matthew Wilcox wrote:
> On Mon, Feb 23, 2026 at 05:39:20PM +0100, David Hildenbrand (Arm) wrote:
>> void pmd_install(struct mm_struct *mm, pmd_t *pmd, pgtable_t *pte);
>>
>> +/**
>> + * sync_with_folio_pmd_zap - sync with concurrent zapping of a folio PMD
>> + * @mm: The mm_struct.
>> + * @pmdp: Pointer to the pmd that was found to be pmd_none().
>> + *
>> + * When we stumble over a pmd_none() without holding the PTL while unmapping a
>> + * folio that could have been mapped at that PMD, it could be that concurrent
>> + * zapping of the PMD is not complete yet. While the PMD might be pmd_none()
>> + * already, the folio might still appear to be mapped (folio_mapped()).
>> + *
>> + * Wait for concurrent zapping to complete by grabbing the PTL.
>> + */
>
> I like this. The one thing we've lost is the name of the function which
> does the zapping, which I think was a helpful detail.
I dropped it as we seem to have a talent to rename functions but to
forget about updating comments.
This very patch is an example of that :)
But well, I used folio_mapped() ... so ...
> Perhaps not to
> someone who's deep in "how page tables work", but I wouldn't know where
> to look for the counterpart to this. So how about:
>
> Option A:
> + * When we stumble over a pmd_none() without holding the PTL while
> + * unmapping a folio that could have been mapped at that PMD,
> + * zap_huge_pmd() may not be complete yet. While the PMD might be pmd_none()
> + * already, the folio might still appear to be mapped (folio_mapped()).
>
> Option B:
> + * When we find a pmd_none() while unmapping a folio without holding
> + * the PTL, zap_huge_pmd() may have cleared the PMD but not yet
> + * modified the folio to indicate that it's unmapped.
Let's do a slightly longer B:
* When we find a pmd_none() while unmapping a folio without holding
* the PTL, zap_huge_pmd() may have cleared the PMD but not yet
* modified the folio to indicate that it's unmapped. Skipping the PMD
* without synchronization could make folio unmapping code assume
* that unmapping failed.
Good? If so, Andrew can you squash or should I resend?
Thanks for the review!
--
Cheers,
David
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-02-23 19:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-23 16:39 [PATCH v1] mm: centralize+fix comments about compound_mapcount() in new sync_with_folio_pmd_zap() David Hildenbrand (Arm)
2026-02-23 17:58 ` Matthew Wilcox
2026-02-23 19:16 ` David Hildenbrand (Arm)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox