* 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