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@xxxxxxxxx> 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@xxxxxxxxx> wrote: > > > > > > > > From: Leah Rumancik <lrumancik@xxxxxxxxxx> > > > > > > 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
