mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] f2fs: zone: fix to don't fail to grab GC target block on zoned device
@ 2026-10-19  9:00 Chao Yu
  2026-10-19 15:40 ` [f2fs-dev] " patchwork-bot+f2fs
  0 siblings, 1 reply; 2+ messages in thread
From: Chao Yu @ 2026-10-19  9:00 UTC (permalink / raw)
  To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, Chao Yu, stable

From: Chao Yu <chao@kernel.org>

With out-of-memory fault injection (inject_type=0x0080800f) on a zoned
device, f2fs stopped checkpoint during GC:

 F2FS-fs (dm-0): inject kmalloc in f2fs_kmalloc of move_data_block+0xc0b/0x12b0
 Workqueue: dm-1_zwplugs blk_zone_wplug_bio_work
 Call Trace:
  <TASK>
  dump_stack_lvl+0x4d/0x70
  f2fs_stop_checkpoint+0x1df/0x5d0
  f2fs_write_end_bio+0xdbb/0x1320
  blk_zone_wplug_bio_work+0x2aa/0x7d0
  process_one_work+0x5c6/0xde0
  worker_thread+0x403/0xb70
  kthread+0x235/0x2e0
  ret_from_fork+0x2f/0x70
  ret_from_fork_asm+0x1a/0x30
  </TASK>
 F2FS-fs (dm-0): Stopped filesystem due to reason: 3

In move_data_block(), the target block is grabbed from the meta cache
after f2fs_allocate_data_block() has allocated newaddr. If grabbing it
fails w/ -ENOMEM, recover_block calls f2fs_do_replace_block() to restore
the old block address and curseg's next_blkoff, which already points
past newaddr, so newaddr is never written. That leaves a hole in a
sequential zone: the next write to the zone is not at the write pointer,
the zone write plug fails it, and f2fs_write_end_bio() stops checkpoint
w/ STOP_CP_REASON_WRITE_FAIL.

move_data_block() allocates newaddr before grabbing its meta page and
goes to recover_block if the grab fails since commit 4356e48e6437
("f2fs crypto: fix incorrect positioning for GCing encrypted data page"),
the meta cache only replaced the meta page w/ a meta cache entry. That
is harmless on a regular device, but it leaves the hole since f2fs
supports host-managed SMR (now zoned block) devices, which only accept
writes at the write pointer of a sequential zone.

If newaddr is in a sequential zone, grab the target block w/
F2FS_CACHE_NOFAIL, so nothing can fail between allocating newaddr and
writing it. In a conventional zone or on a regular device, skipping
newaddr is harmless, so keep the error handling for them.

Cc: stable@kernel.org
Fixes: 52763a4b7a21 ("f2fs: detect host-managed SMR by feature flag")
Fixes: d1b959c87702 ("f2fs: Check zoned block feature for host-managed zoned block devices")
Signed-off-by: Chao Yu <chao@kernel.org>
---
 fs/f2fs/gc.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 926e6976bc22..b6d7ed299f14 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1453,8 +1453,16 @@ static int move_data_block(struct inode *inode, block_t bidx,
 		goto up_out;
 	}
 
+	/*
+	 * If newaddr is in a sequential zone, it must be written once it is
+	 * allocated, otherwise it leaves a hole in the zone, and the following
+	 * write to the zone will fail as an unaligned write, so don't fail
+	 * here.
+	 */
 	tentry = f2fs_grab_cache(META_CACHE(fio.sbi), newaddr,
-					F2FS_CACHE_LOCK_CREATE);
+			F2FS_CACHE_LOCK_CREATE |
+			(f2fs_is_sequential_zone_area(fio.sbi, newaddr) ?
+			 F2FS_CACHE_NOFAIL : 0));
 	if (IS_ERR(tentry)) {
 		err = PTR_ERR(tentry);
 		f2fs_put_cache(sentry, true);
-- 
2.49.0


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [f2fs-dev] [PATCH] f2fs: zone: fix to don't fail to grab GC target block on zoned device
  2026-10-19  9:00 [PATCH] f2fs: zone: fix to don't fail to grab GC target block on zoned device Chao Yu
@ 2026-10-19 15:40 ` patchwork-bot+f2fs
  0 siblings, 0 replies; 2+ messages in thread
From: patchwork-bot+f2fs @ 2026-10-19 15:40 UTC (permalink / raw)
  To: Chao Yu; +Cc: jaegeuk, stable, linux-kernel, linux-f2fs-devel

Hello:

This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim <jaegeuk@kernel.org>:

On Mon, 19 Oct 2026 09:00:32 +0000 you wrote:
> From: Chao Yu <chao@kernel.org>
> 
> With out-of-memory fault injection (inject_type=0x0080800f) on a zoned
> device, f2fs stopped checkpoint during GC:
> 
>  F2FS-fs (dm-0): inject kmalloc in f2fs_kmalloc of move_data_block+0xc0b/0x12b0
>  Workqueue: dm-1_zwplugs blk_zone_wplug_bio_work
>  Call Trace:
>   <TASK>
>   dump_stack_lvl+0x4d/0x70
>   f2fs_stop_checkpoint+0x1df/0x5d0
>   f2fs_write_end_bio+0xdbb/0x1320
>   blk_zone_wplug_bio_work+0x2aa/0x7d0
>   process_one_work+0x5c6/0xde0
>   worker_thread+0x403/0xb70
>   kthread+0x235/0x2e0
>   ret_from_fork+0x2f/0x70
>   ret_from_fork_asm+0x1a/0x30
>   </TASK>
>  F2FS-fs (dm-0): Stopped filesystem due to reason: 3
> 
> [...]

Here is the summary with links:
  - [f2fs-dev] f2fs: zone: fix to don't fail to grab GC target block on zoned device
    https://git.kernel.org/jaegeuk/f2fs/c/14f329117d10

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-10-19 15:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-19  9:00 [PATCH] f2fs: zone: fix to don't fail to grab GC target block on zoned device Chao Yu
2026-10-19 15:40 ` [f2fs-dev] " patchwork-bot+f2fs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®