[GIT PULL] xfs: fix ro mounting with unknown rocompat features

From: "Darrick J. Wong" <djwong@kernel.org>
To: chandan.babu@gmail.com, djwong@kernel.org
Cc: david@fromorbit.com, dchinner@redhat.com,
	linux-xfs@vger.kernel.org, peterz@infradead.org,
	ritesh.list@gmail.com, sandeen@sandeen.net, tglx@linutronix.de
Subject: [GIT PULL] xfs: fix ro mounting with unknown rocompat features
Date: Tue, 19 Sep 2023 09:01:42 -0700	[thread overview]
Message-ID: <169513911841.1384408.4221257193552110896.stg-ugh@frogsfrogsfrogs> (raw)

Hi Chandan,

Please pull this branch with changes for xfs for 6.6-rc2.

As usual, I did a test-merge with the main upstream branch as of a few
minutes ago, and didn't see any conflicts.  Please let me know if you
encounter any problems.

--D

The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:

Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)

are available in the Git repository at:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git tags/fix-ro-mounts-6.6_2023-09-19

for you to fetch changes up to b848f5934d43fee6ed185853784d7dc0f13b7324:

xfs: fix log recovery when unknown rocompat bits are set (2023-09-12 10:31:07 -0700)

Yep, re-doing the pull request because I didn't fill out the form
correctly, my homebrew checkpatch script didn't catch this one quirk,
and the community checkpatch script is so noisy I don't use it, which
I'm sure is inviting flames from all the armchair xfs maintainers out
there.
----------------------------------------------------------------
xfs: fix ro mounting with unknown rocompat features [v2]

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.

v2: change direction of series to allow log recovery on ro mounts

This has been lightly tested with fstests.  Enjoy!

Signed-off-by: Darrick J. Wong <djwong@kernel.org>

----------------------------------------------------------------
Darrick J. Wong (7):
xfs: fix an agbno overflow in __xfs_getfsmap_datadev
xfs: fix per-cpu CIL structure aggregation racing with dying cpus
xfs: use per-mount cpumask to track nonempty percpu inodegc lists
xfs: remove the all-mounts list
xfs: remove CPU hotplug infrastructure
xfs: allow inode inactivation during a ro mount log recovery
xfs: fix log recovery when unknown rocompat bits are set

fs/xfs/libxfs/xfs_sb.c     |  3 +-
fs/xfs/xfs_fsmap.c         | 25 ++++++++++----
fs/xfs/xfs_icache.c        | 78 +++++++++++++++--------------------------
fs/xfs/xfs_icache.h        |  1 -
fs/xfs/xfs_inode.c         | 14 +++++---
fs/xfs/xfs_log.c           | 17 ---------
fs/xfs/xfs_log_cil.c       | 52 +++++++++-------------------
fs/xfs/xfs_log_priv.h      | 14 ++++----
fs/xfs/xfs_mount.h         |  7 ++--
fs/xfs/xfs_super.c         | 86 ++--------------------------------------------
include/linux/cpuhotplug.h |  1 -
11 files changed, 86 insertions(+), 212 deletions(-)