From: sashiko-bot@kernel.org
To: "Konstantin Khorenko" <khorenko@virtuozzo.com>,
"David Hildenbrand" <david@kernel.org>, "Zi Yan" <ziy@nvidia.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Alistair Popple" <apopple@nvidia.com>,
"Dan Williams" <djbw@kernel.org>
Cc: linux-mm@kvack.org, nvdimm@lists.linux.dev
Subject: Re: [PATCH] mm/huge_memory: use folio_dup_file_rmap_pud() in copy_huge_pud()
Date: Sat, 07 Nov 2026 17:05:45 +0000 [thread overview]
Message-ID: <sashiko-outbox-203086@kernel.org> (raw)
In-Reply-To: <20261106-khorenko-vstor-151183-copy_huge_pud-dup-rmap-v1-1-cf8ee4fafabb@virtuozzo.com>
Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] mm: hardware A/D bits discarded for PUD folios in
zap_huge_pud() [1]
--
commit a6bb79712598f2da7fdcc94c9b1b5f8b9aad8851
Author: Konstantin Khorenko <khorenko@virtuozzo.com>
mm/huge_memory: use folio_dup_file_rmap_pud() in copy_huge_pud()
This commit adds folio_dup_file_rmap_pud() to duplicate file rmap mapcounts
at the PUD level and uses it in copy_huge_pud() instead of
folio_add_file_rmap_pud().
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index d0e19d9e6b651..13caf81cb51af 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2100,7 +2100,7 @@ int copy_huge_pud(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
> * TODO: once we support anonymous pages, use
> * folio_try_dup_anon_rmap_*() and split if duplicating fails.
> */
> - folio_add_file_rmap_pud(folio, page, dst_vma);
> + folio_dup_file_rmap_pud(folio, page, dst_vma);
> add_mm_counter(dst_mm, mm_counter_file(folio), HPAGE_PUD_NR);
> }
[Severity: Medium]
This problem wasn't introduced by this patch, but does zap_huge_pud()
discard hardware accessed and dirty bits on the PUD folio [1]?
mm/huge_memory.c:zap_huge_pud() {
...
orig_pud = pudp_huge_get_and_clear_full(vma, addr, pud, tlb->fullmm);
...
} else {
...
page = pud_page(orig_pud);
folio = page_folio(page);
folio_remove_rmap_pud(folio, page, vma);
add_mm_counter(tlb->mm, mm_counter_file(folio), -HPAGE_PUD_NR);
...
}
Unlike zap_huge_pmd(), which checks the cleared entry and calls
folio_mark_accessed() and folio_mark_dirty(), zap_huge_pud() removes the
PUD rmap without propagating the young and dirty bits from orig_pud to the
folio. When unmapping a refcounted Device DAX PUD mapping, those hardware
A/D bits are lost, leaving the folio with stale access and dirty state.
[1] https://sashiko.dev/#/bug/linux-d2fca843-ce3d-48bf-9ef3-bf87872ea6ec
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-khorenko-vstor-151183-copy_huge_pud-dup-rmap-v1-1-cf8ee4fafabb@virtuozzo.com?part=1
next prev parent reply other threads:[~2026-11-07 17:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 17:05 [PATCH] mm/huge_memory: use folio_dup_file_rmap_pud() in copy_huge_pud() Konstantin Khorenko
2026-11-06 21:48 ` David Hildenbrand (Arm)
2026-11-07 17:05 ` sashiko-bot [this message]
2026-11-09 12:57 ` David Hildenbrand (Arm)
2026-11-09 12:58 ` David Hildenbrand
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=sashiko-outbox-203086@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=david@kernel.org \
--cc=djbw@kernel.org \
--cc=khorenko@virtuozzo.com \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=ziy@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.