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

Amir Goldstein
2022-06-08T08:37:38Z

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>
> > >
> > > This first round of patches aims to take care of the easy cases - patches
> > > with the Fixes tag that apply cleanly. I have ~30 more patches identified
> > > which will be tested next, thanks everyone for the various suggestions
> > > for tracking down more bug fixes. No regressions were seen during
> > > testing when running fstests 3 times per config with the following configs:
> >
> > Hi Leah!
> >
> > I'll let the xfs developers comment on the individual patches.
> > General comments about stable process and collaboration.
> >
> > Some of the patches in this series are relevant to 5.10 and even apply
> > cleanly to 5.10 (see below).
> > They are in my queue but I did not get to test them thoroughly yet,
> > because I am working chronologically.
> >
> > To avoid misunderstanding with stable maintainers, when you post to
> > stable, please make sure to state clearly in the cover letter that those
> > patches have only been tested on 5.15.y and should only be applied
> > to 5.15.y.
> > I know you have 5.15 in subject, but I would rather be safe than sorry.
>
> Fair concern, will do.
>
> >
> > Luis has advised me to post up to 10 patches in each round.
> > The rationale is that after we test and patches are applied to stable
> > regressions may be detected and reported by downstream users.
> >
> > Regressions will be easier to bisect if there are less fixes in every
> > LTS release. For this reason, I am holding on to my part 2 patches
> > until 5.10.120 is released. LTS releases are usually on weekly basis
> > so the delay is not much.
> >
> > I don't think that this series is terribly big, so I am fine with you
> > posting it at one go, but please consider splitting it pre 5.16
> > and post 5.16 or any other way that you see fit when you post
> > to stable, but let's wait for xfs developers review - if they tell you to
> > drop a few patches my comment will become moot ;-)
> >
>
> Sure, that is no problem for me, I'll go ahead and split into sets of 10
> or fewer.
>

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.