From nobody Thu Apr 9 23:26:35 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3450F2EB87E; Thu, 5 Mar 2026 08:48:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772700525; cv=none; b=qdlmb8RU8I7QW9uFJcvvtTPf/YxEo27tR3rd9DqGWwTSapg++Z8wR3OpdWcK60VPGZNetXsgXq9gTucLYhEIcH4mDotTBrqylodayjH+9ndofrs5t/iF+QxnbpGaF0ptB7MUwIfmsDcmdcxXA2ZWYrflLMiA8BAjHRFtXz+q4Go= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772700525; c=relaxed/simple; bh=DdpNVFHobZSm3IODHo/SNPr1P30ACq/hjxyY12f+y5Y=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=XHH2SdjOw8GnbDrzCUjTY5HEWv/UFPN8+YpOwqQ31NnI4DriMUMXv/qQlAC81PwbsiK+uAy7GkvFHXv3y9Cje0ejE/DLYtybGBS/Wc8B2+CL+ujvOPPLUb9O21xVWEXEJAtmzMD55vgTnJYThkfsM/wCua47HtWtXTxjO4NBsgQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=kn8yHNHu; arc=none smtp.client-ip=117.135.210.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="kn8yHNHu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=eP /mDGFiSQ8/KzmMyMXfCllLm9rTES59FBoYT5e9FEA=; b=kn8yHNHuzZ2TTpi9/p 2AGQARUrAYeNbm0VMDgnA50qZVC/ywqCY724Kqtb+ks5oZDugCJe7SFcTQG7iDIc R1gkY3ECek0TMZaSUfnl+k0+BMs+XKbXEYpyzOO/cCNU9SpKBCBQaCmuWfQ/2We/ oX1xexNo+9MoKv6gee1QD/Dbs= Received: from pek-lpg-core5.wrs.com (unknown []) by gzga-smtp-mtada-g1-2 (Coremail) with SMTP id _____wD3l0REQ6lpiWT8OA--.49433S2; Thu, 05 Mar 2026 16:48:04 +0800 (CST) From: Robert Garcia To: stable@vger.kernel.org, Chao Yu Cc: Jaegeuk Kim , Daeho Jeong , Robert Garcia , linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: [PATCH 6.12.y] f2fs: fix to avoid migrating empty section Date: Thu, 5 Mar 2026 16:48:03 +0800 Message-Id: <20260305084803.210354-1-rob_garcia@163.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wD3l0REQ6lpiWT8OA--.49433S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxZw4ruw17KF1DuFWDKFW7urg_yoW5ZrWrpF 1rCFn7KrsakF47Zwn7tF15CFyYy34vvF17GrZIg3Wvq3sxJF1F93Z0y3s0gFyxXrWrAFWr Xr9xuryFgw4DAa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UJnYrUUUUU= X-CM-SenderInfo: 5uresw5dufxti6rwjhhfrp/xtbC5gWmEmmpQ0XJpgAA3+ Content-Type: text/plain; charset="utf-8" From: Chao Yu [ Upstream commit d625a2b08c089397d3a03bff13fa8645e4ec7a01 ] It reports a bug from device w/ zufs: F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT F2FS-fs (dm-64): Stopped filesystem due to reason: 4 Thread A Thread B - f2fs_expand_inode_data - f2fs_allocate_pinning_section - f2fs_gc_range - do_garbage_collect w/ segno #x - writepage - f2fs_allocate_data_block - new_curseg - allocate segno #x The root cause is: fallocate on pinning file may race w/ block allocation as above, result in do_garbage_collect() from fallocate() may migrate segment which is just allocated by a log, the log will update segment type in its in-memory structure, however GC will get segment type from on-disk SSA block, once segment type changes by log, we can detect such inconsistency, then shutdown filesystem. In this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE), however segno #173822 was just allocated as data type segment, so in-memory SIT shows type of segno #173822 is 0 (SUM_TYPE_DATA). Change as below to fix this issue: - check whether current section is empty before gc - add sanity checks on do_garbage_collect() to avoid any race case, result in migrating segment used by log. - btw, it fixes misc issue in printed logs: "SSA and SIT" -> "SIT and SSA". Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim [ Use IS_CURSEC instead of is_cursec according to commit c1cfc87e49525 ("f2fs: introduce is_cur{seg,sec}()"). ] Signed-off-by: Robert Garcia --- fs/f2fs/gc.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index 67a93d45ad3a..6e09b80c0c37 100644 --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -1805,6 +1805,13 @@ static int do_garbage_collect(struct f2fs_sb_info *s= bi, GET_SUM_BLOCK(sbi, segno)); f2fs_put_page(sum_page, 0); =20 + if (IS_CURSEC(sbi, GET_SEC_FROM_SEG(sbi, segno))) { + f2fs_err(sbi, "%s: segment %u is used by log", + __func__, segno); + f2fs_bug_on(sbi, 1); + goto skip; + } + if (get_valid_blocks(sbi, segno, false) =3D=3D 0) goto freed; if (gc_type =3D=3D BG_GC && __is_large_section(sbi) && @@ -1815,7 +1822,7 @@ static int do_garbage_collect(struct f2fs_sb_info *sb= i, =20 sum =3D page_address(sum_page); if (type !=3D GET_SUM_TYPE((&sum->footer))) { - f2fs_err(sbi, "Inconsistent segment (%u) type [%d, %d] in SSA and SIT", + f2fs_err(sbi, "Inconsistent segment (%u) type [%d, %d] in SIT and SSA", segno, type, GET_SUM_TYPE((&sum->footer))); f2fs_stop_checkpoint(sbi, false, STOP_CP_REASON_CORRUPTED_SUMMARY); @@ -2079,6 +2086,13 @@ int f2fs_gc_range(struct f2fs_sb_info *sbi, .iroot =3D RADIX_TREE_INIT(gc_list.iroot, GFP_NOFS), }; =20 + /* + * avoid migrating empty section, as it can be allocated by + * log in parallel. + */ + if (!get_valid_blocks(sbi, segno, true)) + continue; + if (IS_CURSEC(sbi, GET_SEC_FROM_SEG(sbi, segno))) continue; =20 --=20 2.34.1