On Thu, Jun 23, 2022 at 12:38 AM Leah Rumancik <leah.rumancik@xxxxxxxxx> wrote: > > On Wed, Jun 22, 2022 at 09:35:19AM -0700, Darrick J. Wong wrote: > > On Wed, Jun 22, 2022 at 09:23:07AM -0700, Darrick J. Wong wrote: > > > On Thu, Jun 16, 2022 at 11:27:41AM -0700, Leah Rumancik wrote: > > > > The patch testing has been increased to 100 runs per test on each > > > > config. A baseline without the patches was established with 100 runs > > > > to help detect hard failures / tests with a high fail rate. Any > > > > failures seen in the backports branch but not in the baseline branch > > > > were then run 1000+ times on both the baseline and backport branches > > > > and the failure rates compared. The failures seen on the 5.15 > > > > baseline are listed at > > > > https://gist.github.com/lrumancik/5a9d85d2637f878220224578e173fc23. > > > > No regressions were seen with these patches. > > > > > > > > To make the review process easier, I have been coordinating with Amir > > > > who has been testing this same set of patches on 5.10. He will be > > > > sending out the corresponding 5.10 series shortly. > > > > > > > > Change log from v1 > > > > (https://lore.kernel.org/all/20220603184701.3117780-1-leah.rumancik@xxxxxxxxx/): > > > > - Increased testing > > > > - Reduced patch set to overlap with 5.10 patches > > > > > > > > Thanks, > > > > Leah > > > > > > > > Brian Foster (1): > > > > xfs: punch out data fork delalloc blocks on COW writeback failure > > > > > > > > Darrick J. Wong (4): > > > > 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 > > > > > > 5.15 already has the vfs fixes to make sync_fs/sync_filesystem actually > > > return error codes, right? > Confirmed "vfs: make sync_filesystem return errors from ->sync_fs" made > it into 5.15.y (935745abcf4c695a18b9af3fbe295e322547a114). Confirmed that it made it into 5.10.y and that 2719c7160dcf ("vfs: make freeze_super abort when sync_filesystem returns error") also made it to both 5.10.y and 5.15.y > > > > > > > > xfs: use setattr_copy to set vfs inode attributes > > > > > > > > Dave Chinner (1): > > > > xfs: check sb_meta_uuid for dabuf buffer recovery > > > > > > > > Rustam Kovhaev (1): > > > > xfs: use kmem_cache_free() for kmem_cache objects > > > > > > > > Yang Xu (1): > > > > xfs: Fix the free logic of state in xfs_attr_node_hasname > > > > > > This one trips me up every time I look at it, but this looks correct. > > > > > > If the answer to the above question is yes, then: > > > Acked-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > I should've mentioned that this is acked-by for patches 1-7, since Amir > > posted a question about patch 8 that seems not to have been answered(?) > > > > (Do all the new setgid inheritance tests actually pass with patch 8 > > applied? The VFS fixes were thorny enough that I'm not as confident > > that they've all been applied to 5.15.y...) > > The setgid tests (ex generic/314, generic/444, generic/673, generic/68[3-7], > xfs/019) ran without issues. The dax config did have failures on both the > baseline and backports branch but the other configs all passed cleanly. > There were some changes to these tests since the last time I updated fstests > though so I'll go ahead and rerun this set to be sure. That's not all. There are also Christian's vfstest tests that also check SGID with and without idmapped mounts. This is especially important for 5.15.y which has idmapped mounts support. Anyway, as agreed, we are dropping this patch for this round. So let's talk procedure - You got Acked-by from Darrick for the entire series minus this one patch, so according to earlier request, please post the v3 diminished series of the 5.15 CANDIDATE to xfs list with Darrick's Acked-by on all patches, to allow developers to see the series in its final form before posting to stable. The cover letter should list the Changes since v2 to express the dropped patch. I don't know what's the customary time to wait for "last notice before merge" but I would say you can send your series to stable in a day or two if there are no last minute comments. Anyway, the post to stable is also public (don't forget to cc xfs list) and after patches are queued to stable there is also time for developers to object. (stable process sends emails to patch authors and reviewers before merging them). I suggest for convention, that the post to stable be tagged as v4 with CANDIDATE prefix removed and the changelog looking something like this: Changes since v3: - Post to stable Changes from v2: - Drop SGID fix - Added Acks from Darrick Changes from v1: (https://lore.kernel.org/all/20220603184701.3117780-1-leah.rumancik@xxxxxxxxx/): - Increased testing - Reduced patch set to overlap with 5.10 patches I will follow the same procedure for 5.10 series as soon as all of Darrick's concerns will be addressed. Thanks, Amir.