From: "Arisu Tachibana" <alicef@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/linux-patches:6.16 commit in: /
Date: Thu, 21 Aug 2025 04:31:08 +0000 (UTC) [thread overview]
Message-ID: <1755742964.c38997df8c108e6158132f7c5d056fce255b9d02.alicef@gentoo> (raw)
commit: c38997df8c108e6158132f7c5d056fce255b9d02
Author: Arisu Tachibana <alicef <AT> gentoo <DOT> org>
AuthorDate: Thu Aug 21 02:22:44 2025 +0000
Commit: Arisu Tachibana <alicef <AT> gentoo <DOT> 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 <alicef <AT> 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 <fdmanana@suse.com>
-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 <ptr1337@cachyos.org>
-Link: https://lore.kernel.org/linux-btrfs/fce139db-4458-4788-bb97-c29acf6cb1df@cachyos.org/
-Reported-by: burneddi <burneddi@protonmail.com>
-Link: https://lore.kernel.org/linux-btrfs/lh4W-Lwc0Mbk-QvBhhQyZxf6VbM3E8VtIvU3fPIQgweP_Q1n7wtlUZQc33sYlCKYd-o6rryJQfhHaNAOWWRKxpAXhM8NZPojzsJPyHMf2qY=@protonmail.com/#t
-Reported-by: Russell Haley <yumpusamongus@gmail.com>
-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 <boris@bur.io>
-Signed-off-by: Filipe Manana <fdmanana@suse.com>
----
- 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
-
next reply other threads:[~2025-08-21 4:31 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 4:31 Arisu Tachibana [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-10-13 11:56 [gentoo-commits] proj/linux-patches:6.16 commit in: / Arisu Tachibana
2025-10-06 12:01 Arisu Tachibana
2025-10-06 11:06 Arisu Tachibana
2025-10-02 14:17 Arisu Tachibana
2025-10-02 14:14 Arisu Tachibana
2025-10-02 13:42 Arisu Tachibana
2025-10-02 13:30 Arisu Tachibana
2025-10-02 13:25 Arisu Tachibana
2025-10-02 3:28 Arisu Tachibana
2025-10-02 3:28 Arisu Tachibana
2025-10-02 3:12 Arisu Tachibana
2025-09-25 12:02 Arisu Tachibana
2025-09-20 6:29 Arisu Tachibana
2025-09-20 6:29 Arisu Tachibana
2025-09-20 5:31 Arisu Tachibana
2025-09-20 5:25 Arisu Tachibana
2025-09-12 3:56 Arisu Tachibana
2025-09-10 6:18 Arisu Tachibana
2025-09-10 5:57 Arisu Tachibana
2025-09-10 5:30 Arisu Tachibana
2025-09-05 14:01 Arisu Tachibana
2025-09-04 15:46 Arisu Tachibana
2025-09-04 15:33 Arisu Tachibana
2025-08-28 16:37 Arisu Tachibana
2025-08-28 16:01 Arisu Tachibana
2025-08-28 15:31 Arisu Tachibana
2025-08-28 15:19 Arisu Tachibana
2025-08-28 15:14 Arisu Tachibana
2025-08-28 15:14 Arisu Tachibana
2025-08-25 0:00 Arisu Tachibana
2025-08-24 23:09 Arisu Tachibana
2025-08-21 4:31 Arisu Tachibana
2025-08-21 1:07 Arisu Tachibana
2025-08-21 1:00 Arisu Tachibana
2025-08-21 0:27 Arisu Tachibana
2025-08-16 5:54 Arisu Tachibana
2025-08-16 5:54 Arisu Tachibana
2025-08-16 5:21 Arisu Tachibana
2025-08-16 4:02 Arisu Tachibana
2025-08-16 3:07 Arisu Tachibana
2025-07-29 7:43 Arisu Tachibana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1755742964.c38997df8c108e6158132f7c5d056fce255b9d02.alicef@gentoo \
--to=alicef@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox