[PATCH] filemap: prefault writes starting beyond EOF

[PATCH] filemap: prefault writes starting beyond EOF

[Hungyu Lin]

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.

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.

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) {
+			status = -EFAULT;
+			break;
+		}
+
 		status = a_ops->write_begin(iocb, mapping, pos, bytes,
 						&folio, &fsdata);
 		if (unlikely(status < 0))

base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
-- 
2.43.0

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

[Kiryl Shutsemau]

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.
> 
> 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.
> 
> 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>

You found the bug, I only pointed out that it is not tmpfs-specific.
Please drop Reported-by and Closes; Suggested-by and Link are enough.

Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

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

[Pedro Falcato]

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.

> 
> 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?

> 
> 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. 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.

-- 
Pedro

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

[Kiryl Shutsemau]

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