]> git.ipfire.org Git - thirdparty/kernel/stable.git/commitdiff
xfs: fix null bno_hint handling in xfs_rtallocate_rtg
authorDarrick J. Wong <djwong@kernel.org>
Mon, 2 Dec 2024 18:57:30 +0000 (10:57 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 19 Dec 2024 17:13:08 +0000 (18:13 +0100)
commit af9f02457f461b23307fe826a37be61ba6e32c92 upstream.

xfs_bmap_rtalloc initializes the bno_hint variable to NULLRTBLOCK (aka
NULLFSBLOCK).  If the allocation request is for a file range that's
adjacent to an existing mapping, it will then change bno_hint to the
blkno hint in the bmalloca structure.

In other words, bno_hint is either a rt block number, or it's all 1s.
Unfortunately, commit ec12f97f1b8a8f didn't take the NULLRTBLOCK state
into account, which means that it tries to translate that into a
realtime extent number.  We then end up with an obnoxiously high rtx
number and pointlessly feed that to the near allocator.  This often
fails and falls back to the by-size allocator.  Seeing as we had no
locality hint anyway, this is a waste of time.

Fix the code to detect a lack of bno_hint correctly.  This was detected
by running xfs/009 with metadir enabled and a 28k rt extent size.

Cc: <stable@vger.kernel.org> # v6.12
Fixes: ec12f97f1b8a8f ("xfs: make the rtalloc start hint a xfs_rtblock_t")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/xfs/xfs_rtalloc.c

index 3a2005a1e673dcc5843a8e8e386c17ec0297e9ad..8caa55b8167467d02b97efc9f87cbfddef25ce80 100644 (file)
@@ -1295,7 +1295,7 @@ xfs_rtallocate(
         * For an allocation to an empty file at offset 0, pick an extent that
         * will space things out in the rt area.
         */
-       if (bno_hint)
+       if (bno_hint != NULLFSBLOCK)
                start = xfs_rtb_to_rtx(args.mp, bno_hint);
        else if (initial_user_data)
                start = xfs_rtpick_extent(args.mp, tp, maxlen);