mbox series

[5.10,v2,0/9] xfs stable patches for 5.10.y (from v5.13+)

Message ID 20220729161609.4071252-1-amir73il@gmail.com (mailing list archive)
Headers show
Series xfs stable patches for 5.10.y (from v5.13+) | expand

Message

Amir Goldstein July 29, 2022, 4:16 p.m. UTC
Hi Greg,

This backport series contains mostly fixes from v5.14 release along
with one fix deferred from the first joint 5.10/5.15 series [1].

The upstream commit f8d92a66e810 ("xfs: prevent UAF in
xfs_log_item_in_current_chkpt") was already applied to 5.15.y, but its
5.10.y backport was more involved (required two non trivial dependency
patches), so it needed more time for review and testing.

Per Darrick's recommendation, on top of the usual regression tests,
I also ran the "recoveryloop" tests group for an extended period of
time to test for rare regressions.

Some recoveryloop tests were failing at rates less frequent than 1/100,
but no change in failure rate was observed between baseline (v5.10.131)
and the backport branch.

There was one exceptional test, xfs/455, that was reporting data
corruptions after crash at very low rate - less frequent than 1/1000
on both baseline and backport branch.

It is hard to draw solid conclusions with such rare failures, but the
test was run >10,000 times on baseline and >20,000 times on backport
branch, so as far as our test coverage can attest, these backports are
not introducing any obvious xfs regressions to 5.10.y.

Thanks,
Amir.

Changes from [v1]:
- Survived a week of crash recovery loop
- Added Acked-by Darrick
- CC stable

[1] https://lore.kernel.org/linux-xfs/20220623203641.1710377-1-leah.rumancik@gmail.com/
[v1] https://lore.kernel.org/linux-xfs/20220726092125.3899077-1-amir73il@gmail.com/

Brian Foster (2):
  xfs: hold buffer across unpin and potential shutdown processing
  xfs: remove dead stale buf unpin handling code

Christoph Hellwig (1):
  xfs: refactor xfs_file_fsync

Darrick J. Wong (3):
  xfs: prevent UAF in xfs_log_item_in_current_chkpt
  xfs: fix log intent recovery ENOSPC shutdowns when inactivating inodes
  xfs: force the log offline when log intent item recovery fails

Dave Chinner (3):
  xfs: xfs_log_force_lsn isn't passed a LSN
  xfs: logging the on disk inode LSN can make it go backwards
  xfs: Enforce attr3 buffer recovery order

 fs/xfs/libxfs/xfs_log_format.h  | 11 ++++-
 fs/xfs/libxfs/xfs_types.h       |  1 +
 fs/xfs/xfs_buf_item.c           | 60 ++++++++++--------------
 fs/xfs/xfs_buf_item_recover.c   |  1 +
 fs/xfs/xfs_dquot_item.c         |  2 +-
 fs/xfs/xfs_file.c               | 81 ++++++++++++++++++++-------------
 fs/xfs/xfs_inode.c              | 10 ++--
 fs/xfs/xfs_inode_item.c         |  4 +-
 fs/xfs/xfs_inode_item.h         |  2 +-
 fs/xfs/xfs_inode_item_recover.c | 39 ++++++++++++----
 fs/xfs/xfs_log.c                | 30 ++++++------
 fs/xfs/xfs_log.h                |  4 +-
 fs/xfs/xfs_log_cil.c            | 32 +++++--------
 fs/xfs/xfs_log_priv.h           | 15 +++---
 fs/xfs/xfs_log_recover.c        |  5 +-
 fs/xfs/xfs_mount.c              | 10 +++-
 fs/xfs/xfs_trans.c              |  6 +--
 fs/xfs/xfs_trans.h              |  4 +-
 18 files changed, 179 insertions(+), 138 deletions(-)

Comments

Greg KH Aug. 1, 2022, 8:41 a.m. UTC | #1
On Fri, Jul 29, 2022 at 06:16:00PM +0200, Amir Goldstein wrote:
> Hi Greg,
> 
> This backport series contains mostly fixes from v5.14 release along
> with one fix deferred from the first joint 5.10/5.15 series [1].
> 
> The upstream commit f8d92a66e810 ("xfs: prevent UAF in
> xfs_log_item_in_current_chkpt") was already applied to 5.15.y, but its
> 5.10.y backport was more involved (required two non trivial dependency
> patches), so it needed more time for review and testing.
> 
> Per Darrick's recommendation, on top of the usual regression tests,
> I also ran the "recoveryloop" tests group for an extended period of
> time to test for rare regressions.
> 
> Some recoveryloop tests were failing at rates less frequent than 1/100,
> but no change in failure rate was observed between baseline (v5.10.131)
> and the backport branch.
> 
> There was one exceptional test, xfs/455, that was reporting data
> corruptions after crash at very low rate - less frequent than 1/1000
> on both baseline and backport branch.
> 
> It is hard to draw solid conclusions with such rare failures, but the
> test was run >10,000 times on baseline and >20,000 times on backport
> branch, so as far as our test coverage can attest, these backports are
> not introducing any obvious xfs regressions to 5.10.y.

Now queued up, thanks!

greg k-h