From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0F2CC15827B for ; Sat, 16 Aug 2025 05:21:15 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id F0F6833E6B8 for ; Sat, 16 Aug 2025 05:21:14 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id F2609110280; Sat, 16 Aug 2025 05:21:13 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id E8555110280 for ; Sat, 16 Aug 2025 05:21:13 +0000 (UTC) Received: from oystercatcher.gentoo.org (oystercatcher.gentoo.org [148.251.78.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 9B155340CD8 for ; Sat, 16 Aug 2025 05:21:13 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id E0E66333F for ; Sat, 16 Aug 2025 05:21:11 +0000 (UTC) From: "Arisu Tachibana" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Arisu Tachibana" Message-ID: <1755320227.cae8c76b9da5adc2674fdeb2ce15c61d57b6b511.alicef@gentoo> Subject: [gentoo-commits] proj/linux-patches:6.16 commit in: / X-VCS-Repository: proj/linux-patches X-VCS-Files: 0000_README 1900_btrfs_fix_log_tree_replay_failure.patch X-VCS-Directories: / X-VCS-Committer: alicef X-VCS-Committer-Name: Arisu Tachibana X-VCS-Revision: cae8c76b9da5adc2674fdeb2ce15c61d57b6b511 X-VCS-Branch: 6.16 Date: Sat, 16 Aug 2025 05:21:11 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: 526f33c3-8587-4aa2-802b-ffa7b8a22960 X-Archives-Hash: 7541cced0595fb46596725c6560f04a6 commit: cae8c76b9da5adc2674fdeb2ce15c61d57b6b511 Author: Arisu Tachibana gentoo org> AuthorDate: Sat Aug 16 04:57:07 2025 +0000 Commit: Arisu Tachibana gentoo org> CommitDate: Sat Aug 16 04:57:07 2025 +0000 URL: https://gitweb.gentoo.org/proj/linux-patches.git/commit/?id=cae8c76b Add patch 1900 fix log tree replay failure on btrfs Signed-off-by: Arisu Tachibana gentoo.org> 0000_README | 4 + 1900_btrfs_fix_log_tree_replay_failure.patch | 143 +++++++++++++++++++++++++++ 2 files changed, 147 insertions(+) diff --git a/0000_README b/0000_README index 60a31446..208a4856 100644 --- a/0000_README +++ b/0000_README @@ -59,6 +59,10 @@ Patch: 1730_parisc-Disable-prctl.patch From: https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git Desc: prctl: Temporarily disable prctl(PR_SET_MDWE) on parisc +Patch: 1900_btrfs_fix_log_tree_replay_failure.patch +From: https://gitlab.com/cki-project/kernel-ark/-/commit/e6c71b29fab08fd0ab55d2f83c4539d68d543895 +Desc: btrfs: fix log tree replay failure due to file with 0 links and extents + Patch: 2000_BT-Check-key-sizes-only-if-Secure-Simple-Pairing-enabled.patch From: https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtmann.org/raw Desc: Bluetooth: Check key sizes only when Secure Simple Pairing is enabled. See bug #686758 diff --git a/1900_btrfs_fix_log_tree_replay_failure.patch b/1900_btrfs_fix_log_tree_replay_failure.patch new file mode 100644 index 00000000..335bb7f2 --- /dev/null +++ b/1900_btrfs_fix_log_tree_replay_failure.patch @@ -0,0 +1,143 @@ +From e6c71b29fab08fd0ab55d2f83c4539d68d543895 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 30 Jul 2025 19:18:37 +0100 +Subject: [PATCH] btrfs: fix log tree replay failure due to file with 0 links + and extents + +If we log a new inode (not persisted in a past transaction) that has 0 +links and extents, then log another inode with an higher inode number, we +end up with failing to replay the log tree with -EINVAL. The steps for +this are: + +1) create new file A +2) write some data to file A +3) open an fd on file A +4) unlink file A +5) fsync file A using the previously open fd +6) create file B (has higher inode number than file A) +7) fsync file B +8) power fail before current transaction commits + +Now when attempting to mount the fs, the log replay will fail with +-ENOENT at replay_one_extent() when attempting to replay the first +extent of file A. The failure comes when trying to open the inode for +file A in the subvolume tree, since it doesn't exist. + +Before commit 5f61b961599a ("btrfs: fix inode lookup error handling +during log replay"), the returned error was -EIO instead of -ENOENT, +since we converted any errors when attempting to read an inode during +log replay to -EIO. + +The reason for this is that the log replay procedure fails to ignore +the current inode when we are at the stage LOG_WALK_REPLAY_ALL, our +current inode has 0 links and last inode we processed in the previous +stage has a non 0 link count. In other words, the issue is that at +replay_one_extent() we only update wc->ignore_cur_inode if the current +replay stage is LOG_WALK_REPLAY_INODES. + +Fix this by updating wc->ignore_cur_inode whenever we find an inode item +regardless of the current replay stage. This is a simple solution and easy +to backport, but later we can do other alternatives like avoid logging +extents or inode items other than the inode item for inodes with a link +count of 0. + +The problem with the wc->ignore_cur_inode logic has been around since +commit f2d72f42d5fa ("Btrfs: fix warning when replaying log after fsync +of a tmpfile") but it only became frequent to hit since the more recent +commit 5e85262e542d ("btrfs: fix fsync of files with no hard links not +persisting deletion"), because we stopped skipping inodes with a link +count of 0 when logging, while before the problem would only be triggered +if trying to replay a log tree created with an older kernel which has a +logged inode with 0 links. + +A test case for fstests will be submitted soon. + +Reported-by: Peter Jung +Link: https://lore.kernel.org/linux-btrfs/fce139db-4458-4788-bb97-c29acf6cb1df@cachyos.org/ +Reported-by: burneddi +Link: https://lore.kernel.org/linux-btrfs/lh4W-Lwc0Mbk-QvBhhQyZxf6VbM3E8VtIvU3fPIQgweP_Q1n7wtlUZQc33sYlCKYd-o6rryJQfhHaNAOWWRKxpAXhM8NZPojzsJPyHMf2qY=@protonmail.com/#t +Reported-by: Russell Haley +Link: https://lore.kernel.org/linux-btrfs/598ecc75-eb80-41b3-83c2-f2317fbb9864@gmail.com/ +Fixes: f2d72f42d5fa ("Btrfs: fix warning when replaying log after fsync of a tmpfile") +Reviewed-by: Boris Burkov +Signed-off-by: Filipe Manana +--- + fs/btrfs/tree-log.c | 45 +++++++++++++++++++++++++++++---------------- + 1 file changed, 29 insertions(+), 16 deletions(-) + +diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c +index e05140ce95be9..2fb9e7bfc9077 100644 +--- a/fs/btrfs/tree-log.c ++++ b/fs/btrfs/tree-log.c +@@ -321,8 +321,7 @@ struct walk_control { + + /* + * Ignore any items from the inode currently being processed. Needs +- * to be set every time we find a BTRFS_INODE_ITEM_KEY and we are in +- * the LOG_WALK_REPLAY_INODES stage. ++ * to be set every time we find a BTRFS_INODE_ITEM_KEY. + */ + bool ignore_cur_inode; + +@@ -2410,23 +2409,30 @@ static int replay_one_buffer(struct btrfs_root *log, struct extent_buffer *eb, + + nritems = btrfs_header_nritems(eb); + for (i = 0; i < nritems; i++) { +- btrfs_item_key_to_cpu(eb, &key, i); ++ struct btrfs_inode_item *inode_item; + +- /* inode keys are done during the first stage */ +- if (key.type == BTRFS_INODE_ITEM_KEY && +- wc->stage == LOG_WALK_REPLAY_INODES) { +- struct btrfs_inode_item *inode_item; +- u32 mode; ++ btrfs_item_key_to_cpu(eb, &key, i); + +- inode_item = btrfs_item_ptr(eb, i, +- struct btrfs_inode_item); ++ if (key.type == BTRFS_INODE_ITEM_KEY) { ++ inode_item = btrfs_item_ptr(eb, i, struct btrfs_inode_item); + /* +- * If we have a tmpfile (O_TMPFILE) that got fsync'ed +- * and never got linked before the fsync, skip it, as +- * replaying it is pointless since it would be deleted +- * later. We skip logging tmpfiles, but it's always +- * possible we are replaying a log created with a kernel +- * that used to log tmpfiles. ++ * An inode with no links is either: ++ * ++ * 1) A tmpfile (O_TMPFILE) that got fsync'ed and never ++ * got linked before the fsync, skip it, as replaying ++ * it is pointless since it would be deleted later. ++ * We skip logging tmpfiles, but it's always possible ++ * we are replaying a log created with a kernel that ++ * used to log tmpfiles; ++ * ++ * 2) A non-tmpfile which got its last link deleted ++ * while holding an open fd on it and later got ++ * fsynced through that fd. We always log the ++ * parent inodes when inode->last_unlink_trans is ++ * set to the current transaction, so ignore all the ++ * inode items for this inode. We will delete the ++ * inode when processing the parent directory with ++ * replay_dir_deletes(). + */ + if (btrfs_inode_nlink(eb, inode_item) == 0) { + wc->ignore_cur_inode = true; +@@ -2434,6 +2440,13 @@ static int replay_one_buffer(struct btrfs_root *log, struct extent_buffer *eb, + } else { + wc->ignore_cur_inode = false; + } ++ } ++ ++ /* Inode keys are done during the first stage. */ ++ if (key.type == BTRFS_INODE_ITEM_KEY && ++ wc->stage == LOG_WALK_REPLAY_INODES) { ++ u32 mode; ++ + ret = replay_xattr_deletes(wc->trans, root, log, + path, key.objectid); + if (ret) +-- +GitLab +