* Re: [PATCH] shmem: do not extend i_size when no data was copied
[not found] <20261025164619.89992-1-dennylin0707@gmail.com>
@ 2026-10-26 15:34 ` Kiryl Shutsemau
2026-10-26 15:48 ` Jan Kara
0 siblings, 1 reply; 3+ messages in thread
From: Kiryl Shutsemau @ 2026-10-26 15:34 UTC (permalink / raw)
To: Hungyu Lin, willy, jack
Cc: hughd, baolin.wang, akpm, dave.hansen, linux-fsdevel, linux-mm,
linux-kernel, stable
On Sun, Oct 25, 2026 at 04:46:19PM +0000, Hungyu Lin wrote:
> shmem_write_end() advances i_size to pos + copied even when copied is
> zero. A buffered write past EOF can therefore extend a tmpfs file
> without writing any data.
+ willy, jack, fsdevel.
This doesn't seem to be tmpfs-specific, right? I see the same with ext4.
simple_write_end() and generic_write_end() check pos + copied the same
way, so filesystems that use them through generic_perform_write() are
affected too.
It makes me think maybe generic_perform_write() is the right place to
fix it. Hm?
> Moving prefaulting to the slow write path makes this easy to reproduce:
> a one-byte pwrite() at offset 4096 into an empty memfd, with an unreadable
> source buffer, fails with EFAULT but leaves the file size at 4096.
> generic_perform_write() calls ->write_end() with copied == 0 before
> trying to fault in the source buffer.
>
> Only extend i_size when data was copied. Leave the existing folio
> handling unchanged so successful writes, retries and preallocated
> pages retain their current behavior.
>
> Fixes: 665575cff098 ("filemap: move prefaulting out of hot write path")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
> mm/shmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index d97fc32e7c94..55287c370c73 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -3487,7 +3487,7 @@ shmem_write_end(const struct kiocb *iocb, struct address_space *mapping,
> {
> struct inode *inode = mapping->host;
>
> - if (pos + copied > inode->i_size)
> + if (copied && pos + copied > inode->i_size)
> i_size_write(inode, pos + copied);
>
> if (!folio_test_uptodate(folio)) {
> --
> 2.43.0
>
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] shmem: do not extend i_size when no data was copied
2026-10-26 15:34 ` [PATCH] shmem: do not extend i_size when no data was copied Kiryl Shutsemau
@ 2026-10-26 15:48 ` Jan Kara
2026-10-26 18:18 ` Kiryl Shutsemau
0 siblings, 1 reply; 3+ messages in thread
From: Jan Kara @ 2026-10-26 15:48 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Hungyu Lin, willy, jack, hughd, baolin.wang, akpm, dave.hansen,
linux-fsdevel, linux-mm, linux-kernel, stable
On Mon 26-10-26 15:34:08, Kiryl Shutsemau wrote:
> On Sun, Oct 25, 2026 at 04:46:19PM +0000, Hungyu Lin wrote:
> > shmem_write_end() advances i_size to pos + copied even when copied is
> > zero. A buffered write past EOF can therefore extend a tmpfs file
> > without writing any data.
>
> + willy, jack, fsdevel.
>
> This doesn't seem to be tmpfs-specific, right? I see the same with ext4.
>
> simple_write_end() and generic_write_end() check pos + copied the same
> way, so filesystems that use them through generic_perform_write() are
> affected too.
>
> It makes me think maybe generic_perform_write() is the right place to
> fix it. Hm?
Well, that would be nice. But how'd you like to do that? i_size update is
the responsibility of ->write_end and we have to call ->write_end if copied
== 0 so that is undoes what ->write_begin has prepared.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] shmem: do not extend i_size when no data was copied
2026-10-26 15:48 ` Jan Kara
@ 2026-10-26 18:18 ` Kiryl Shutsemau
0 siblings, 0 replies; 3+ messages in thread
From: Kiryl Shutsemau @ 2026-10-26 18:18 UTC (permalink / raw)
To: Jan Kara
Cc: Hungyu Lin, willy, hughd, baolin.wang, akpm, dave.hansen,
linux-fsdevel, linux-mm, linux-kernel, stable
On Mon, Oct 26, 2026 at 04:48:58PM +0100, Jan Kara wrote:
> On Mon 26-10-26 15:34:08, Kiryl Shutsemau wrote:
> > On Sun, Oct 25, 2026 at 04:46:19PM +0000, Hungyu Lin wrote:
> > > shmem_write_end() advances i_size to pos + copied even when copied is
> > > zero. A buffered write past EOF can therefore extend a tmpfs file
> > > without writing any data.
> >
> > + willy, jack, fsdevel.
> >
> > This doesn't seem to be tmpfs-specific, right? I see the same with ext4.
> >
> > simple_write_end() and generic_write_end() check pos + copied the same
> > way, so filesystems that use them through generic_perform_write() are
> > affected too.
> >
> > It makes me think maybe generic_perform_write() is the right place to
> > fix it. Hm?
>
> Well, that would be nice. But how'd you like to do that? i_size update is
> the responsibility of ->write_end and we have to call ->write_end if copied
> == 0 so that is undoes what ->write_begin has prepared.
Hm.
A zero-length copy only moves i_size if the write starts beyond EOF.
So we can bring the prefault back just for that case, before
->write_begin():
if (unlikely(pos > i_size_read(mapping->host)) &&
fault_in_iov_iter_readable(i, bytes) == bytes) {
status = -EFAULT;
break;
}
Overwrites and appends keep skipping the prefault. It is racy against
a concurrent munmap(), as it was before 665575cff098, but that is
userspace racing with itself.
The per-filesystem alternative is a 'copied &&' in every ->write_end.
And generic_write_end() cannot take it as is: generic_cont_expand_simple()
relies on a zero-length ->write_end() extending i_size. So we need some
replacement.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-26 18:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20261025164619.89992-1-dennylin0707@gmail.com>
2026-10-26 15:34 ` [PATCH] shmem: do not extend i_size when no data was copied Kiryl Shutsemau
2026-10-26 15:48 ` Jan Kara
2026-10-26 18:18 ` Kiryl Shutsemau
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox