From nobody Fri Apr 3 22:15:13 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 97311C2FF; Mon, 9 Mar 2026 08:33:07 +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=1773045193; cv=none; b=mzeWNtHKsDZvGdHppYWNJ/SRi3cRldZIcVXqN1kiC4XSPos1+Mz0ZMSDqvL8Z6jrNIIVNsQ35PaFHfB+i+6V/QTIFkIeRtNkscfZYcggRPyBIaTv9AbIsF0b5LtJ3S7WjQq0agQiuU/G/MP/s6I6nK7qsa00oSbNPyIQjEFcdZk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773045193; c=relaxed/simple; bh=3+KsM/i2GE0dsvEaH4AXLFyjxYB6RfjOYZrOEvAVgfY=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=TTjCHGrccJS23YCdQV7LoRsUTPXp42xUy7kDsIfnhTM4dJRU+/OPFFim8LRiBJBqyv2iQxcuz0LEBzTEVtwAbehZ+pgt1ru3x88ubFpD9Diu+WQR6+MrF5/TaJMLzgUG79pVemcHYYtNXTly8nrr0AcbTdIZ+g6WcG7IXa3p0i8= 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=PndsVnYg; 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="PndsVnYg" 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=EE leLpm7u4mAEEE1CXuictIykzFh26/ppdcuLkRYW9Y=; b=PndsVnYgaDdCqbjc9v VCYtZfVDcRbOT/mQaEgbvuJr5YR683jDmVh8yLYywxZ66g9k8J1IsM6b5g+UB7vG wzHMcFk7Q2APKogd7NUSPuOFy1EiPsjNVQyJe+FFKnH1NmfuFbu6JCyVMc1bKLCj 99qlXDeCt9dm5eUTipGYFxrOA= Received: from pek-lpg-core5.wrs.com (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wCnDnOcha5pR2wjRQ--.26049S2; Mon, 09 Mar 2026 16:32:28 +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.6.y] f2fs: fix to avoid migrating empty section Date: Mon, 9 Mar 2026 16:32:27 +0800 Message-Id: <20260309083227.3241109-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: _____wCnDnOcha5pR2wjRQ--.26049S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxZw4ruw17KF1DuFWDKFW7urg_yoW5ZFy7pF 1rCFn7Krsakr4xZ3WktF15CFyYy34vvF17GrZIga1vq3sxJF1FqFn0y3s0qF1xXryrAFWY qry7uryFgwn8Aa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UL_-PUUUUU= X-CM-SenderInfo: 5uresw5dufxti6rwjhhfrp/xtbDARyO+WmuhZwBRgAA3z 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 8122135bb1ff..816a5aa263e6 100644 --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -1742,6 +1742,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) && @@ -1752,7 +1759,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))); set_sbi_flag(sbi, SBI_NEED_FSCK); f2fs_stop_checkpoint(sbi, false, @@ -2005,6 +2012,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; + do_garbage_collect(sbi, segno, &gc_list, FG_GC, dry_run_sections =3D=3D 0); put_gc_inode(&gc_list); --=20 2.34.1