commit:     d96679025b88dd13a8f0068426bf68f8144ac048
Author:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
AuthorDate: Tue Aug 13 17:13:24 2024 +0000
Commit:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
CommitDate: Tue Aug 13 17:13:24 2024 +0000
URL:        https://gitweb.gentoo.org/proj/linux-patches.git/commit/?id=d9667902

xfs: xfs_finobt_count_blocks() walks the wrong btree

Signed-off-by: Mike Pagano <mpagano <AT> gentoo.org>

 0000_README                            |  4 +++
 1900_xfs-finobt-count-blocks-fix.patch | 55 ++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+)

diff --git a/0000_README b/0000_README
index 8befc23c..aa55e020 100644
--- a/0000_README
+++ b/0000_README
@@ -71,6 +71,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_xfs-finobt-count-blocks-fix.patch
+From:   
https://lore.kernel.org/linux-xfs/20240813152530.GF6051@frogsfrogsfrogs/T/#mdc718f38912ccc1b9b53b46d9adfaeff0828b55f
+Desc:   xfs: xfs_finobt_count_blocks() walks the wrong btree
+
 Patch:  2000_BT-Check-key-sizes-only-if-Secure-Simple-Pairing-enabled.patch
 From:   
https://lore.kernel.org/linux-bluetooth/[email protected]/raw
 Desc:   Bluetooth: Check key sizes only when Secure Simple Pairing is enabled. 
See bug #686758

diff --git a/1900_xfs-finobt-count-blocks-fix.patch 
b/1900_xfs-finobt-count-blocks-fix.patch
new file mode 100644
index 00000000..02f60712
--- /dev/null
+++ b/1900_xfs-finobt-count-blocks-fix.patch
@@ -0,0 +1,55 @@
+xfs: xfs_finobt_count_blocks() walks the wrong btree
+
+From: Dave Chinner <[email protected]>
+
+As a result of the factoring in commit 14dd46cf31f4 ("xfs: split
+xfs_inobt_init_cursor"), mount started taking a long time on a
+user's filesystem.  For Anders, this made mount times regress from
+under a second to over 15 minutes for a filesystem with only 30
+million inodes in it.
+
+Anders bisected it down to the above commit, but even then the bug
+was not obvious. In this commit, over 20 calls to
+xfs_inobt_init_cursor() were modified, and some we modified to call
+a new function named xfs_finobt_init_cursor().
+
+If that takes you a moment to reread those function names to see
+what the rename was, then you have realised why this bug wasn't
+spotted during review. And it wasn't spotted on inspection even
+after the bisect pointed at this commit - a single missing "f" isn't
+the easiest thing for a human eye to notice....
+
+The result is that xfs_finobt_count_blocks() now incorrectly calls
+xfs_inobt_init_cursor() so it is now walking the inobt instead of
+the finobt. Hence when there are lots of allocated inodes in a
+filesystem, mount takes a -long- time run because it now walks a
+massive allocated inode btrees instead of the small, nearly empty
+free inode btrees. It also means all the finobt space reservations
+are wrong, so mount could potentially given ENOSPC on kernel
+upgrade.
+
+In hindsight, commit 14dd46cf31f4 should have been two commits - the
+first to convert the finobt callers to the new API, the second to
+modify the xfs_inobt_init_cursor() API for the inobt callers. That
+would have made the bug very obvious during review.
+
+Fixes: 14dd46cf31f4 ("xfs: split xfs_inobt_init_cursor")
+Reported-by: Anders Blomdell <[email protected]>
+Signed-off-by: Dave Chinner <[email protected]>
+---
+ fs/xfs/libxfs/xfs_ialloc_btree.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/xfs/libxfs/xfs_ialloc_btree.c 
b/fs/xfs/libxfs/xfs_ialloc_btree.c
+index 496e2f72a85b..797d5b5f7b72 100644
+--- a/fs/xfs/libxfs/xfs_ialloc_btree.c
++++ b/fs/xfs/libxfs/xfs_ialloc_btree.c
+@@ -749,7 +749,7 @@ xfs_finobt_count_blocks(
+       if (error)
+               return error;
+ 
+-      cur = xfs_inobt_init_cursor(pag, tp, agbp);
++      cur = xfs_finobt_init_cursor(pag, tp, agbp);
+       error = xfs_btree_count_blocks(cur, tree_blocks);
+       xfs_btree_del_cursor(cur, error);
+       xfs_trans_brelse(tp, agbp);

Reply via email to