Re: [PATCH 5.15 00/15] xfs stable candidate patches for 5.15.y

[Leah Rumancik <leah.rumancik@gmail.com>]

On Wed, Jun 08, 2022 at 10:56:17AM +0300, Amir Goldstein wrote:
> On Mon, Jun 6, 2022 at 8:42 PM Leah Rumancik <leah.rumancik@gmail.com> wrote:
> >
> > On Sat, Jun 04, 2022 at 11:38:35AM +0300, Amir Goldstein wrote:
> > > On Sat, Jun 4, 2022 at 6:53 AM Leah Rumancik <leah.rumancik@gmail.com> wrote:
> > > >
> > > > From: Leah Rumancik <lrumancik@google.com>
> > > >
> 
> FWIW, the following subset of your 5.15 patches (or backported version thereof)
> have been sitting in my xfs-5.10.y-8 tag since Saturday and have been
> spinning in kdevops since (~20 auto runs) with no regressions observed
> from v5.10.y baseline:
> 
> xfs: punch out data fork delalloc blocks on COW writeback failure
> xfs: remove all COW fork extents when remounting readonly
> xfs: prevent UAF in xfs_log_item_in_current_chkpt
> xfs: only bother with sync_filesystem during readonly remount
> xfs: use setattr_copy to set vfs inode attributes
> xfs: check sb_meta_uuid for dabuf buffer recovery
> xfs: use kmem_cache_free() for kmem_cache objects
> xfs: Fix the free logic of state in xfs_attr_node_hasname
> 
> So perhaps you could use that as the smaller subset for first posting.
> To reduce review burden on xfs maintainers, I could break out of the
> chronological patches order and use the same subset for my next set
> of candidates for 5.10 after testing them in isolation on top of xfs-5.10.y-3
> (at least the ones that apply out of order).
> 
> Thanks,
> Amir.

Sure, good idea! I was going to split it into a smaller batch anyways,
so this selection works for me.

Best,
Leah