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 8F45A15827B for ; Thu, 21 Aug 2025 04:31:11 +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 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 75CD0340824 for ; Thu, 21 Aug 2025 04:31:11 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 53E1C11055E; Thu, 21 Aug 2025 04:31:10 +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 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 494F911055E for ; Thu, 21 Aug 2025 04:31:10 +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 F0140340824 for ; Thu, 21 Aug 2025 04:31:09 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id 6DA8234B8 for ; Thu, 21 Aug 2025 04:31:08 +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: <1755742964.c38997df8c108e6158132f7c5d056fce255b9d02.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: c38997df8c108e6158132f7c5d056fce255b9d02 X-VCS-Branch: 6.16 Date: Thu, 21 Aug 2025 04:31:08 +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: 4ae72ab4-9b75-434c-ad3f-3f7dff3de666 X-Archives-Hash: bbbfbbab3b363220d1f73402e28b7bc0 commit: c38997df8c108e6158132f7c5d056fce255b9d02 Author: Arisu Tachibana gentoo org> AuthorDate: Thu Aug 21 02:22:44 2025 +0000 Commit: Arisu Tachibana gentoo org> CommitDate: Thu Aug 21 02:22:44 2025 +0000 URL: https://gitweb.gentoo.org/proj/linux-patches.git/commit/?id=c38997df Remove 1900_btrfs_fix_log_tree_replay_failure.patch Signed-off-by: Arisu Tachibana gentoo.org> 0000_README | 4 - 1900_btrfs_fix_log_tree_replay_failure.patch | 143 --------------------------- 2 files changed, 147 deletions(-) diff --git a/0000_README b/0000_README index 8d6c88e6..60e64ca1 100644 --- a/0000_README +++ b/0000_README @@ -63,10 +63,6 @@ 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 deleted file mode 100644 index 335bb7f2..00000000 --- a/1900_btrfs_fix_log_tree_replay_failure.patch +++ /dev/null @@ -1,143 +0,0 @@ -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 -