Re: [PATCH 1/2] xfs: load rtbitmap and rtsummary extent mapping btrees at mount time

[Dave Chinner <david@fromorbit.com>]

On Sun, Oct 02, 2022 at 11:20:02AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> It turns out that GETFSMAP and online fsck have had a bug for years due
> to their use of ILOCK_SHARED to coordinate their linear scans of the
> realtime bitmap.  If the bitmap file's data fork happens to be in BTREE
> format and the scan occurs immediately after mounting, the incore bmbt
> will not be populated, leading to ASSERTs tripping over the incorrect
> inode state.  Because the bitmap scans always lock bitmap buffers in
> increasing order of file offset, it is appropriate for these two callers
> to take a shared ILOCK to improve scalability.
> 
> To fix this problem, load both data and attr fork state into memory when
> mounting the realtime inodes.  Realtime metadata files aren't supposed
> to have an attr fork so the second step is likely a nop.
> 
> On most filesystems this is unlikely since the rtbitmap data fork is
> usually in extents format, but it's possible to craft a filesystem that
> will by fragmenting the free space in the data section and growfsing the
> rt section.
> 
> Fixes: 4c934c7dd60c ("xfs: report realtime space information via the rtbitmap")
> Also-Fixes: 46d9bfb5e706 ("xfs: cross-reference the realtime bitmap")
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  fs/xfs/xfs_rtalloc.c |   56 ++++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 52 insertions(+), 4 deletions(-)

Looks fine.

Reviewed-by: Dave Chinner <dchinner@redhat.com>

-- 
Dave Chinner
david@fromorbit.com