Re: [PATCH] fs/proc/task_mmu: check THP exclusivity for each subpage

[David Hildenbrand (Arm)]

On 11/1/26 20:02, Andrew Morton wrote:
> On Sun,  1 Nov 2026 09:01:00 -0800 Kelvin Zhang <zhangxp1998@xxxxxxxxx> 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.
> 
> Thanks.
> 
> I don't want to pick on you at all, but this is a classic changelog - I
> see this pattern so often.
> 
> 	a) here's what the code does
> 
> 	b) here's why that's wrong
> 
> 	c) here's how I fixed it.
> 
> But that's missing a very important bullet point:
> 
> 	a) here's what the code does
> 
> 	b) here's why that's wrong
> 
> 	c) here's how this affects users
> 
> 	d) here's how I fixed it.
> 
> see?  This omission is so common!  And I might have sent one or two
> emails asking people for the missing info.
> 
> For the missing c), how does this sound?
> 
> : With transparent huge pages, /proc/PID/pagemap can incorrectly
> : report shared pages as exclusive, or vice versa, after fork() and
> : partial unmapping.  This can mislead memory-analysis and
> : checkpoint/restore tools.  Actual mappings and copy-on-write behavior
> : are unaffected.
> 
> And now that we have our statement of userspace impact, busy non-mm
> downstream readers of this patch can easily see why your proposed
> cc:stable is justified.
> 
> 
> Also, it would be helpful to show brief before-and-after excerpts from
> /proc/PID/pagemap to help others understand the impact of the change. 
> But I don't think we need a v2 just for this.

See my reply. I'm not sure what to best do here, but I want to use this as an
opportunity to say "see, nobody noticed in 1.5 years; and it was found be code
analysis then, so let's simplify it".

So it's either straight to [1] or a "let's do i first the old way" followed by
[1]. I would just do [1] immediately.

Because nobody cares about that flag.


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

-- 
Cheers,

David