Hi Eric, I found the following patch series of yours: [PATCH 0/2] xfs: swapext replay fixes [PATCH 1/2] xfs: handle bad flags in xfs_recover_inode_owner_change [PATCH 2/2] xfs: clear XFS_ILOG_[AD]OWNER for non-btree formats at https://lore.kernel.org/linux-xfs/81b35377-47d9-2421-ba5c-537ac6c8c021@xxxxxxxxxx/ which is fixing a kernel panic during log replay. We have this exact kernel panic in kernel 4.14.99 LTS. However, I do not see that these patches made it into Linux. I do see a different patch of yours[1] that made it into Linux 4.17. It fixes a failure of log replay (which doesn't cause a kernel panic),which we see as well. We see exactly the same assert in xfs_iformat_fork(), we also run fsr. Can you please clarify what's the status of the first patch series? Thanks, Alex. [1] commit dc1baa715bbfbb1902da942d06497e79b40e7bc7 Author: Eric Sandeen <sandeen@xxxxxxxxxxx> Date: Wed Mar 28 17:48:08 2018 -0700 xfs: do not log/recover swapext extent owner changes for deleted inodes Today if we run xfs_fsr and crash[1], log replay can fail because the recovery code tries to instantiate the donor inode from disk to replay the swapext, but it's been deleted and we get verifier failures when we try to read the inode off disk with i_mode == 0. This fixes both sides: We don't log the swapext change if the inode has been deleted, and we don't try to recover it either. [1] or if systemd doesn't cleanly unmount root, as it is wont to do ... Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx> Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
