linux-kernel - Re: [PATCHv2 2/2] mm/truncate: Unmap large folio on split failure

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: <eaa8023f-f3e1-239d-a020-52f50df873e7@google.com>
Date: Wed, 29 Oct 2025 02:12:48 -0700 (PDT)
From: Hugh Dickins <hughd@...gle.com>
To: Kiryl Shutsemau <kirill@...temov.name>
cc: Hugh Dickins <hughd@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
    David Hildenbrand <david@...hat.com>, 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
Subject: Re: [PATCHv2 2/2] mm/truncate: Unmap large folio on split failure

On Mon, 27 Oct 2025, Kiryl Shutsemau wrote:
> On Mon, Oct 27, 2025 at 03:10:29AM -0700, Hugh Dickins wrote:
...
> 
> > Aside from shmem/tmpfs, it does seem to me that this patch is
> > doing more work than it needs to (but how many lines of source
> > do we want to add to avoid doing work in the failed split case?):
> > 
> > The intent is to enable SIGBUS beyond EOF: but the changes are
> > being applied unnecessarily to hole-punch in addition to truncation.
> 
> I am not sure much it should apply to hole-punch. Filesystem folks talk
> about writing to a folio beyond round_up(i_size, PAGE_SIZE) being
> problematic for correctness. I have no clue if the same applies to
> writing to hole-punched parts of the folio.
> 
> Dave, any comments?
> 
> Hm. But if it is problematic it has be caught on fault. We don't do
> this. It will be silently mapped.

There are strict rules about what happens beyond i_size, hence this
patch.  But hole-punch has no persistent "i_size" to define it, and
silently remapping in a fresh zeroed page is the correct behaviour.

So the patch is making more work than is needed for hole-punch.

But I am thinking there of the view from above, from userspace.
If I think of the view from below, from the filesystem, then I'm
not at all sure how a filesystem is expected to deal with a failed
folio_split - and that goes beyond this patch, and therefore I
don't think it should concern you in this patch.

If a filesystem is asked to punch a hole, but mm cannot split the
folio which covers that hole, then page cache and filesystem are
left out of synch?  And if filesystem thinks one block has been
freed, and it's the last block in that filesystem, and it's then
given out to someone else, then our unsplit folio hides an ENOSPC?

Maybe this has all been well thought out, and each large folio
filesystem deals with it appropriately somehow; but I wouldn't
know, since a tmpfs is simply backed by its page cache.

Hugh