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> > > > > > > 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.
