linux-kernel - Re: [PATCHv2 1/2] mm/memory: Do not populate page table entries beyond i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9646894c-01ef-90b9-0c55-4bdfe3aabffd@google.com>
Date: Wed, 29 Oct 2025 01:31:45 -0700 (PDT)
From: Hugh Dickins <hughd@...gle.com>
To: David Hildenbrand <david@...hat.com>
cc: Hugh Dickins <hughd@...gle.com>, Kiryl Shutsemau <kirill@...temov.name>, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    Matthew Wilcox <willy@...radead.org>, 
    Alexander Viro <viro@...iv.linux.org.uk>, 
    Christian Brauner <brauner@...nel.org>, 
    Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
    "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
    Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, 
    Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, 
    Rik van Riel <riel@...riel.com>, Harry Yoo <harry.yoo@...cle.com>, 
    Johannes Weiner <hannes@...xchg.org>, 
    Shakeel Butt <shakeel.butt@...ux.dev>, 
    Baolin Wang <baolin.wang@...ux.alibaba.com>, 
    "Darrick J. Wong" <djwong@...nel.org>, Dave Chinner <david@...morbit.com>, 
    linux-mm@...ck.org, linux-fsdevel@...r.kernel.org, 
    linux-kernel@...r.kernel.org, Kiryl Shutsemau <kas@...nel.org>
Subject: Re: [PATCHv2 1/2] mm/memory: Do not populate page table entries
 beyond i_size

On Mon, 27 Oct 2025, David Hildenbrand wrote:
...
> 
> Just so we are on the same page: this is not about which folio sizes we
> allocate (like what Baolin fixed) but what/how much to map.
> 
> I guess this patch here would imply the following changes
> 
> 1) A file with a size that is not PMD aligned will have the last (unaligned
> part) not mapped by PMDs.
> 
> 2) Once growing a file, the previously-last-part would not be mapped by PMDs.

Yes, the v2 patch was so, and the v3 patch fixes it.

khugepaged might have fixed it up later on, I suppose.

Hmm, does hpage_collapse_scan_file() or collapse_pte_mapped_thp()
want a modification, to prevent reinserting a PMD after a failed
non-shmem truncation folio_split?  And collapse_file() after a
successful non-shmem truncation folio_split?

Conversely, shouldn't MADV_COLLAPSE be happy to give you a PMD
if the map size permits, even when spanning EOF?

> 
> Of course, we would have only mapped the last part of the file by PMDs if the
> VMA would have been large enough in the first place. I'm curious, is that
> something that is commonly done by applications with shmem files (map beyond
> eof)?

Setting aside the very common case of mapping a fraction of PAGE_SIZE
beyond EOF...

I do not know whether it's common to map a >= PAGE_SIZE fraction of
HPAGE_PMD_SIZE beyond EOF, but it has often been sensible to do so.
For example, imagine (using x86_64 numbers) a 4MiB map of a 3MiB
file on huge tmpfs, requiring two TLB entries for the whole file.

Hugh