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

[Kiryl Shutsemau <kirill@shutemov.name>]

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.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov