From: Kiryl Shutsemau <kas@kernel.org>
To: Hungyu Lin <dennylin0707@gmail.com>, willy@infradead.org, jack@suse.cz
Cc: hughd@google.com, baolin.wang@linux.alibaba.com,
akpm@linux-foundation.org, dave.hansen@linux.intel.com,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] shmem: do not extend i_size when no data was copied
Date: Mon, 26 Oct 2026 15:34:08 +0000 [thread overview]
Message-ID: <at9xXRhD2xZhszEj@thinkstation> (raw)
In-Reply-To: <20261025164619.89992-1-dennylin0707@gmail.com>
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
next prev parent reply other threads:[~2026-10-26 15:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 16:46 [PATCH] shmem: do not extend i_size when no data was copied Hungyu Lin
2026-10-26 15:34 ` Kiryl Shutsemau [this message]
2026-10-26 15:48 ` Jan Kara
2026-10-26 18:18 ` Kiryl Shutsemau
2026-10-26 16:36 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=at9xXRhD2xZhszEj@thinkstation \
--to=kas@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=dave.hansen@linux.intel.com \
--cc=dennylin0707@gmail.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.