mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Kelvin Zhang <zhangxp1998@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org
Cc: "Liam R . Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
	Pedro Falcato <pfalcato@suse.de>,
	Kalesh Singh <kaleshsingh@google.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] fs/proc/task_mmu: check THP exclusivity for each subpage
Date: Sun, 1 Nov 2026 19:07:49 +0100	[thread overview]
Message-ID: <54617273-262f-4e17-b912-8b07113ca45c@kernel.org> (raw)
In-Reply-To: <4c1b393a4b04bd94e4f1c7879ae04e1793eb0931.1793552446.git.zhangxp1998@gmail.com>

On 11/1/26 18:01, Kelvin Zhang wrote:
> A PMD-mapped THP can contain subpages with different mapcounts. For
> example, after fork(), the child can unmap only part of the THP. The
> parent retains its PMD mapping, while the remaining child mappings
> are PTE mappings.
> 
> pagemap_pmd_range_thp() passes the same initial page to
> __folio_page_mapped_exclusively() for every pagemap entry. With
> CONFIG_PAGE_MAPCOUNT=y, this applies the first subpage's exclusivity
> to all entries, falsely setting or clearing PM_MMAP_EXCLUSIVE for
> subpages with different sharing.
> 
> Pass page + idx to check the subpage corresponding to each entry, as
> was done before converting to __folio_page_mapped_exclusively(). The
> index already accounts for reads starting partway through the PMD.
> The conservative whole-folio check without CONFIG_PAGE_MAPCOUNT is
> unchanged.
> 
> Fixes: eb16876971ea ("fs/proc/task_mmu: remove per-page mapcount dependency for PM_MMAP_EXCLUSIVE (CONFIG_NO_PAGE_MAPCOUNT)")
> Cc: stable@vger.kernel.org # 6.15+
> Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com>
> ---
> Tested on x86-64 under QEMU/KVM with CONFIG_TRANSPARENT_HUGEPAGE=y
> and CONFIG_PAGE_MAPCOUNT=y, using the same test binary before and after
> this change. After fork(), the child unmaps the first, second, middle,
> or last 4 KiB subpage, while the parent retains a PMD mapping. Both
> bulk pagemap reads and reads starting inside the PMD are checked.
> 
> Across three repetitions (12 cases), the unmodified kernel fails 24 of
> 84 assertions; with this change all 84 pass. Fully private and fully
> shared PMD controls pass before and after the fix.
> 

How was this found. Through an LLM or because there was actually a problem in
practice?

Why do you care about this information to be reliable.

If the answer is "I don't care, I don't care, an LLM reported so I blindly
submit a fix" we might just perform the switch to the CONFIG_NO_PAGE_MAPCOUNT
variant directly.


https://lore.kernel.org/linux-mm/20260412-mapcount-v1-4-05e8dfab52e0@kernel.org/

-- 
Cheers,

David

  reply	other threads:[~2026-11-01 18:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-01 17:01 Kelvin Zhang
2026-11-01 18:07 ` David Hildenbrand (Arm) [this message]
2026-11-01 18:18   ` David Hildenbrand (Arm)
2026-11-01 18:27     ` Kelvin Zhang
2026-11-01 19:02 ` Andrew Morton

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=54617273-262f-4e17-b912-8b07113ca45c@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=kaleshsingh@google.com \
    --cc=liam@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=pfalcato@suse.de \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@kernel.org \
    --cc=zhangxp1998@gmail.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

all inboxes | Powered by JetHome®