Merge tag 'fix-ro-mounts-6.6_2023-09-12' of https://git.kernel.org/pub/scm/linux...
authorChandan Babu R <chandanbabu@kernel.org>
Wed, 13 Sep 2023 04:44:02 +0000 (10:14 +0530)
committerChandan Babu R <chandanbabu@kernel.org>
Wed, 13 Sep 2023 04:44:02 +0000 (10:14 +0530)
commitf41d7d70b0f27a2f03a8117223a653d30e064465
treeacf4dff940c67f16ae21b10c05dcf19fd1ed3b62
parent0a229c935a8a0e0af1447f93128201bbfd3bb171
parent74ad4693b6473950e971b3dc525b5ee7570e05d0
Merge tag 'fix-ro-mounts-6.6_2023-09-12' of https://git./linux/kernel/git/djwong/xfs-linux into xfs-6.6-fixesA

xfs: fix ro mounting with unknown rocompat features

Dave pointed out some failures in xfs/270 when he upgraded Debian
unstable and util-linux started using the new mount apis.  Upon further
inquiry I noticed that XFS is quite a hot mess when it encounters a
filesystem with unrecognized rocompat bits set in the superblock.

Whereas we used to allow readonly mounts under these conditions, a
change to the sb write verifier several years ago resulted in the
filesystem going down immediately because the post-mount log cleaning
writes the superblock, which trips the sb write verifier on the
unrecognized rocompat bit.  I made the observation that the ROCOMPAT
features RMAPBT and REFLINK both protect new log intent item types,
which means that we actually cannot support recovering the log if we
don't recognize all the rocompat bits.

Therefore -- fix inode inactivation to work when we're recovering the
log, disallow recovery when there's unrecognized rocompat bits, and
don't clean the log if doing so would trip the rocompat checks.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
* tag 'fix-ro-mounts-6.6_2023-09-12' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
  xfs: fix log recovery when unknown rocompat bits are set
  xfs: allow inode inactivation during a ro mount log recovery