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: <iqzgqvkin6istylyqqias7bwulhh2s6l6aqepssk6ptfu5dddy@q2rfk3wewcbz>
Date: Wed, 29 Oct 2025 17:10:45 +0000
From: Kiryl Shutsemau <kirill@...temov.name>
To: "Darrick J. Wong" <djwong@...nel.org>
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>, 
	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 Wed, Oct 29, 2025 at 08:19:47AM -0700, Darrick J. Wong wrote:
> On Wed, Oct 29, 2025 at 10:21:53AM +0000, Kiryl Shutsemau wrote:
> > On Wed, Oct 29, 2025 at 02:12:48AM -0700, Hugh Dickins wrote:
> > > 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.
> > 
> > I missed that we seems to be issuing vm_ops->page_mkwrite() on remaping
> > the page, so it is not completely silent for filesystem and can do its
> > thing to re-allocate metadata (or whatever) after hole-punch.
> > 
> > So, I see unmap on punch-hole being justified.
> 
> Most hole punching implementations in filesystems will take i_rwsem and
> mmap_invalidate lock, flush the range to disk and unmap the pagecache
> for all the fsblocks around that range, and only then update the file
> space mappings.  If the unmap fails because a PMD couldn't be split,
> then we'll just return that error to userspace and they can decide what
> to do when fallocate() fails.

Unmap does not fail and PMD can be split at any time. But split of large
folios can fail if there's an external pin on it.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov