Re: [PATCH] filemap: prefault writes starting beyond EOF

[Kiryl Shutsemau <kas@kernel.org>]

On Thu, Nov 05, 2026 at 12:33:16PM +0000, Pedro Falcato wrote:
> On Wed, Nov 04, 2026 at 07:10:02AM +0000, Hungyu Lin wrote:
> > Since prefaulting moved to the slow write path, a buffered write can reach
> > ->write_begin() and ->write_end() before discovering that its source buffer
> > is unreadable. Several filesystems can extend i_size in these callbacks
> > even when no data was copied. For example, a one-byte pwrite() at offset
> > 4096 into an empty file can fail with EFAULT but leave a 4096-byte file.
> 
> I've been following this discussion rather passively on the other thread, so
> I'll ask my stupid question: Why is this a problem? Yes, it's a bit of
> weird behavior, but system calls are generally not expected to behave
> super sanely in the case of bad input/weird errors.

The input does not have to be bad. Write from an mmap() of a file that
another process has truncated: write() fails with EFAULT and the
destination file has grown anyway. I see it on ext4 and tmpfs. Before
665575cff098 the file was left alone

> > 
> > Prefault the source before ->write_begin() when the write position is
> > beyond EOF, and return EFAULT if no source bytes can be made readable.
> > Overwrites and appends continue to skip this prefault. Keep the existing
> > slow-path faulting for forward progress after a failed atomic copy.
> > 
> > This also leaves intentional zero-length ->write_end() calls used by
> > generic_cont_expand_simple() unchanged. As with the previous prefaulting
> > behavior, a concurrent userspace unmap can still race with the later copy.
> 
> Ok, so it's still racy? What do you do if you can't fault it in at all?
> You still get a hole?

Only if the buffer goes away between the prefault and the copy, e.g.
another thread munmap()s it mid-write. That is userspace racing with
itself, and every write had that window before 665575cff098.

> > Fixes: 665575cff098 ("filemap: move prefaulting out of hot write path")
> > Reported-by: Kiryl Shutsemau <kas@kernel.org>
> > Closes: https://lore.kernel.org/linux-mm/at9xXRhD2xZhszEj@thinkstation/
> > Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> > Link: https://lore.kernel.org/all/at-XtWBQg3jv3H8Z@thinkstation/
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> > ---
> > 
> >  mm/filemap.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index b74bc1e5015c6f318333427f223b9f42061a6213..30414d55412b84f11ebe98b8eea607ee8c04eef5 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -4389,6 +4389,16 @@ ssize_t generic_perform_write(struct kiocb *iocb, struct iov_iter *i)
> >  			break;
> >  		}
> >  
> > +		/*
> > +		 * Some filesystems can extend i_size even when nothing was copied.
> > +		 * Prefault writes beyond EOF to catch unreadable source buffers.
> > +		 */
> > +		if (unlikely(pos > i_size_read(mapping->host)) &&
> > +		    fault_in_iov_iter_readable(i, bytes) == bytes) {
> 
> I say this doesn't matter, and if you pass insane inputs you get
> insane outputs.

As I mentioned above, it can happen with pretty legitimate input.

> Even more so considering this is racy, e.g races
> against munmap(), mremap(), mprotect(), memory poisoning, and other things
> like truncated memory mapped files sending out a SIGBUS (or uffd) :)
> 
> I don't think it makes to add random prefault loops in hopes this makes
> for saner semantics.

A buffer that is already unmapped, PROT_NONE, poisoned or beyond EOF of
its file fails the prefault, and the file is not touched. Only the races
in your list get through.

It is one prefault, not a loop, and only for writes that start beyond
EOF. Overwrites and appends keep the fast path.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov