From: <gregkh@linuxfoundation.org>
To: qwjhust@gmail.com,chao@kernel.org,jaegeuk@kernel.org,qiwenjie@xiaomi.com
Cc: <stable@vger.kernel.org>
Subject: FAILED: patch "[PATCH] f2fs: keep atomic write retry from zeroing original data" failed to apply to 6.1-stable tree
Date: Thu, 02 Jul 2026 15:11:03 +0200 [thread overview]
Message-ID: <2026070203-junior-occupancy-679e@gregkh> (raw)
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 6d874b65aadce56ac78f76129dbcfc2599b638f8
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026070203-junior-occupancy-679e@gregkh' --subject-prefix 'PATCH 6.1.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 6d874b65aadce56ac78f76129dbcfc2599b638f8 Mon Sep 17 00:00:00 2001
From: Wenjie Qi <qwjhust@gmail.com>
Date: Wed, 27 May 2026 20:06:28 +0800
Subject: [PATCH] f2fs: keep atomic write retry from zeroing original data
A partial atomic write reserves a block in the COW inode before reading the
original data page for the untouched bytes in that page.
If that read fails, write_begin returns an error but leaves the COW inode
entry as NEW_ADDR. A retry of the same partial write then finds the COW
entry, treats it as existing COW data, and f2fs_write_begin() zeroes the
whole folio because blkaddr is NEW_ADDR.
If the retry is committed, the bytes outside the retried write range are
committed as zeroes instead of preserving the original file contents.
Only use the COW inode as the read source when it already has a real data
block. If the COW entry is still NEW_ADDR, treat it as a reservation to
reuse: keep reading the old data from the original inode and avoid
reserving or accounting the same atomic block again.
Cc: stable@kernel.org
Fixes: 3db1de0e582c ("f2fs: change the current atomic write way")
Signed-off-by: Wenjie Qi <qiwenjie@xiaomi.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index d83a21998ec2..edda2ff72073 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3862,6 +3862,7 @@ static int prepare_atomic_write_begin(struct f2fs_sb_info *sbi,
pgoff_t index = folio->index;
int err = 0;
block_t ori_blk_addr = NULL_ADDR;
+ bool cow_has_reserved_block = false;
/* If pos is beyond the end of file, reserve a new block in COW inode */
if ((pos & PAGE_MASK) >= i_size_read(inode))
@@ -3871,9 +3872,11 @@ static int prepare_atomic_write_begin(struct f2fs_sb_info *sbi,
err = __find_data_block(cow_inode, index, blk_addr);
if (err) {
return err;
- } else if (*blk_addr != NULL_ADDR) {
+ } else if (__is_valid_data_blkaddr(*blk_addr)) {
*use_cow = true;
return 0;
+ } else if (*blk_addr == NEW_ADDR) {
+ cow_has_reserved_block = true;
}
if (is_inode_flag_set(inode, FI_ATOMIC_REPLACE))
@@ -3886,10 +3889,13 @@ static int prepare_atomic_write_begin(struct f2fs_sb_info *sbi,
reserve_block:
/* Finally, we should reserve a new block in COW inode for the update */
- err = __reserve_data_block(cow_inode, index, blk_addr, node_changed);
- if (err)
- return err;
- inc_atomic_write_cnt(inode);
+ if (!cow_has_reserved_block) {
+ err = __reserve_data_block(cow_inode, index, blk_addr,
+ node_changed);
+ if (err)
+ return err;
+ inc_atomic_write_cnt(inode);
+ }
if (ori_blk_addr != NULL_ADDR)
*blk_addr = ori_blk_addr;
next reply other threads:[~2026-07-02 13:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 13:11 gregkh [this message]
2026-07-03 14:02 ` [PATCH 6.1.y] f2fs: keep atomic write retry from zeroing original data Sasha Levin
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=2026070203-junior-occupancy-679e@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=qiwenjie@xiaomi.com \
--cc=qwjhust@gmail.com \
--cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox