On Sun, Oct 02, 2022 at 11:20:02AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@xxxxxxxxxx>
>
> 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@xxxxxxxxxx>
> ---
> fs/xfs/xfs_rtalloc.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 52 insertions(+), 4 deletions(-)
Looks fine.
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
--
Dave Chinner
david@xxxxxxxxxxxxx
