On Thu, May 26, 2022 at 6:01 PM Leah Rumancik <leah.rumancik@xxxxxxxxx> wrote: > > On Wed, May 25, 2022 at 02:23:10PM -0700, Darrick J. Wong wrote: > > Hi everyone, > > > > 3. fstesting -- new patches proposed for stable branches shouldn't > > introduce new regressions, and ideally there would also be a regression > > test that would now pass. As Dave and I have stated in the past, > > fstests is a big umbrella of a test suite, which implies that A/B > > testing is the way to go. I think at least Zorro and I would like to > > improve the tagging in fstests to make it more obvious which tests > > contain enough randomness that they cannot be expected to behave 100% > > reliably. > It would be nice to find an agreement on testing requirements. I have > attached some ideas on configs/number of tests/etc as well as the status > of my work on 5.15 below. > > > > a> I've been following the recent fstests threads, and it seems to me > > that there are really two classes of users -- sustaining people who want > > fstests to run reliably so they can tell if their backports have broken > > anything; and developers, who want the randomness to try to poke into > > dusty corners of the filesystem. Can we make it easier to associate > > random bits of data (reliability rates, etc.) with a given fstests > > configuration? And create a test group^Wtag for the tests that rely on > > RNGs to shake things up? > This would be great! > > > > > > > Thoughts? Flames? > > > > --D > This thread had good timing :) I have been working on setting up > some automated testing. Currently, 5.15.y is our priority so I have > started working on this branch. > > Patches are being selected by simply searching for the “Fixes” > tag and applying if the commit-to-be-fixed is in the stable branch, > but AUTOSEL would be nice, so I’ll start playing around with that. > Amir, it would be nice to sync up the patch selection process. I can > help share the load, especially for 5.15. > I would like that :) > Selecting just the tagged “Fixes” for 5.15.y for patches through > 5.17.2, 15 patches were found and applied - if there are no > complaints about the testing setup, I can go ahead and send out this > batch: > > c30a0cbd07ec xfs: use kmem_cache_free() for kmem_cache objects > 5ca5916b6bc9 xfs: punch out data fork delalloc blocks on COW writeback failure > a1de97fe296c xfs: Fix the free logic of state in xfs_attr_node_hasname > 1090427bf18f xfs: remove xfs_inew_wait > 089558bc7ba7 xfs: remove all COW fork extents when remounting readonly > 7993f1a431bc xfs: only run COW extent recovery when there are no live extents > 09654ed8a18c xfs: check sb_meta_uuid for dabuf buffer recovery > f8d92a66e810 xfs: prevent UAF in xfs_log_item_in_current_chkpt > b97cca3ba909 xfs: only bother with sync_filesystem during readonly remount > eba0549bc7d1 xfs: don't generate selinux audit messages for capability testing > e014f37db1a2 xfs: use setattr_copy to set vfs inode attributes > 70447e0ad978 xfs: async CIL flushes need pending pushes to be made stable > c8c568259772 xfs: don't include bnobt blocks when reserving free block pool > cd6f79d1fb32 xfs: run callbacks before waking waiters in xlog_state_shutdown_callbacks > 919edbadebe1 xfs: drop async cache flushes from CIL commits. > Here are my selection for v5.15..v5.17: * 1cd231d9fdb1 - (tag: xfs-5.10.y-7) xfs: use setattr_copy to set vfs inode attributes * af09d052db41 - xfs: fallocate() should call file_modified() * 0daebb90e096 - xfs: reject crazy array sizes being fed to XFS_IOC_GETBMAP* * 35d876873c28 - xfs: prevent UAF in xfs_log_item_in_current_chkpt * 796e9e00071d - xfs: xfs_log_force_lsn isn't passed a LSN * fa33747dd25b - xfs: refactor xfs_file_fsync * 374a05b9a2de - xfs: check sb_meta_uuid for dabuf buffer recovery * 0b66f78d6af1 - (tag: xfs-5.10.y-6) xfs: remove all COW fork extents when remounting readonly * 44caa4c7aaf4 - xfs: remove incorrect ASSERT in xfs_rename * 4133fc82c95d - xfs: punch out data fork delalloc blocks on COW writeback failure The branch of the moment is at: https://github.com/amir73il/linux/commits/xfs-5.10.y But I keep force pushing the branch and tags when dropping patches from the queue. Note that only half of those commits have Fixes: tag. As I explained, I got to them by removing all the non-fixes and non-relevant commits and then tried to evaluate the remaining commits individually. This was only made scalable because I was working at the patch series level and not at commit level, although at many times, a single fix patch was selected from within a non-fix series. Note that many of the fixes that you selected are impact waves of big performance improvements that got merged after 5.10, so were not relevant for my 5.10.y selection. Thanks, Amir.
