From: Kiryl Shutsemau <kas@kernel.org>
To: Hungyu Lin <dennylin0707@gmail.com>
Cc: brauner@kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz,
willy@infradead.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] buffer: avoid extending i_size after failed writes
Date: Tue, 3 Nov 2026 12:12:20 +0000 [thread overview]
Message-ID: <aunPPm1d3G6yVCLC@thinkstation> (raw)
In-Reply-To: <20261103072234.55611-1-dennylin0707@gmail.com>
On Tue, Nov 03, 2026 at 07:22:34AM +0000, Hungyu Lin wrote:
> generic_write_end() updates i_size to pos + copied even when a nonempty
> write copied no data. Since prefaulting moved to the slow write path, a
> pwrite() past EOF from an unreadable buffer can fail with EFAULT after
> extending the file to the write offset.
>
> For example, on ext2, a one-byte pwrite() at offset 4096 into an empty
> file fails with EFAULT but leaves a 4096-byte file.
>
> Require copied data before extending i_size for a nonempty write. Keep
> zero-length write_end() calls working, since generic_cont_expand_simple()
> uses them for expanding truncate operations.
>
> Also call pagecache_isize_extended() only when i_size changed. Otherwise,
> blocking the size update would leave its endpoint beyond EOF and trigger
> its warning.
>
> Fixes: 665575cff098 ("filemap: move prefaulting out of hot write path")
> Reported-by: Kiryl Shutsemau <kas@kernel.org>
> Link: https://lore.kernel.org/linux-mm/at9xXRhD2xZhszEj@thinkstation/
> Cc: stable@vger.kernel.org
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
Jan is okay with what I proposed here:
https://lore.kernel.org/all/at-XtWBQg3jv3H8Z@thinkstation
Do you want to give it a try instead? Or want me to submit a proper patch?
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-11-03 12:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 7:22 [PATCH] buffer: avoid extending i_size after failed writes Hungyu Lin
2026-11-03 12:12 ` Kiryl Shutsemau [this message]
2026-11-03 19:07 ` Hungyu Lin
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=aunPPm1d3G6yVCLC@thinkstation \
--to=kas@kernel.org \
--cc=brauner@kernel.org \
--cc=dennylin0707@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--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.