| Message ID | 20220617100641.1653164-1-amir73il@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | xfs stable candidate patches for 5.10.y (v5.15+) | expand |
On Fri, Jun 17, 2022 at 01:06:30PM +0300, Amir Goldstein wrote: > Hi all, > > Previously posted candidates for 5.10.y followed chronological release > order. > > Parts 1 and 2 of fixes from v5.10..v5.12 have already been applied to > v5.10.121. > > Part 3 (from 5.13) has already been posted for review [3] on June 6, > but following feedback from Dave, I changed my focus to get the same > set of patches tested and reviewed for 5.10.y/5.15.y. > > I do want to ask you guys to also find time to review part 3, because > we have a lot of catching up to do for 5.10.y, so we need to chew at > this debt at a reasonable rate. > > This post has the matching set of patches for 5.10.y that goes with > Leah's first set of candidates for 5.15.y [1]. > > Most of the fixes are from v5.15..v5.17 except for patch 11 (v5.18-rc1). > All fix patches have been tagged with Fixes: by the author. > > The patches have been soaking in kdepops since Sunday. They passed more > than 30 auto group runs with several different versions of xfsprogs. > > The differences from Leah's 5.15.y: > - It is 11 patches and not 8 because of dependencies > - Patches 6,7 are non-fixes backported as dependency to patch 8 - > they have "backported .* for dependency" in their commit message > - Patches 3,4,11 needed changes to apply to 5.10.y - they have a > "backport" related comment in their commit message to explain what > changes were needed > - Patch 10 is a fix from v5.12 that is re-posted as a dependency for > patch 11 > > Darrick, > > As the author patches 4,11 and sole reviewer of patch 3 (a.k.a > the non-cleanly applied patches), please take a closer look at those. > > Patch 10 has been dropped from my part 2 candidates following concerns > raised by Dave and is now being re-posted following feedback from > Christian and Christoph [2]. > > If there are still concerns about patches 10 or 11, please raise a flag. > I can drop either of these patches before posting to stable if anyone > feels that they need more time to soak in master. At the current moment (keep in mind that I have 2,978 more emails to get through before I'm caught up), I think it's safe to say that for patches 1-5: Acked-by: Darrick J. Wong <djwong@kernel.org> (patch 9 also, but see the reply I just sent for that one about grabbing the sync_fs fixes too) The log changes are going to take more time to go through, since that stuff is always tricky and /not/ something for me to be messing with at 4:45pm. --D > Thanks, > Amir. > > [1] https://lore.kernel.org/linux-xfs/20220616182749.1200971-1-leah.rumancik@gmail.com/ > [2] https://lore.kernel.org/linux-xfs/CAOQ4uxg4=m9zEFbDAKXx7CP7HYiMwtsYSJvq076oKpy-OhK1uw@mail.gmail.com/ > [3] https://lore.kernel.org/linux-xfs/20220606160537.689915-1-amir73il@gmail.com/ > > Brian Foster (1): > xfs: punch out data fork delalloc blocks on COW writeback failure > > Christoph Hellwig (2): > xfs: refactor xfs_file_fsync > xfs: fix up non-directory creation in SGID directories > > 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 > xfs: use setattr_copy to set vfs inode attributes > > Dave Chinner (2): > xfs: check sb_meta_uuid for dabuf buffer recovery > xfs: xfs_log_force_lsn isn't passed a LSN > > 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 > > fs/xfs/libxfs/xfs_attr.c | 13 +++--- > fs/xfs/libxfs/xfs_types.h | 1 + > fs/xfs/xfs_aops.c | 15 +++++-- > fs/xfs/xfs_buf_item.c | 2 +- > fs/xfs/xfs_buf_item_recover.c | 2 +- > fs/xfs/xfs_dquot_item.c | 2 +- > fs/xfs/xfs_extfree_item.c | 6 +-- > fs/xfs/xfs_file.c | 81 +++++++++++++++++++++-------------- > fs/xfs/xfs_inode.c | 24 +++++------ > fs/xfs/xfs_inode_item.c | 4 +- > fs/xfs/xfs_inode_item.h | 2 +- > fs/xfs/xfs_iops.c | 56 ++---------------------- > fs/xfs/xfs_log.c | 27 ++++++------ > fs/xfs/xfs_log.h | 4 +- > fs/xfs/xfs_log_cil.c | 32 ++++++-------- > fs/xfs/xfs_log_priv.h | 15 +++---- > fs/xfs/xfs_pnfs.c | 3 +- > fs/xfs/xfs_super.c | 21 ++++++--- > fs/xfs/xfs_trans.c | 6 +-- > fs/xfs/xfs_trans.h | 4 +- > 20 files changed, 149 insertions(+), 171 deletions(-) > > -- > 2.25.1 >
On Thu, Jun 23, 2022 at 2:45 AM Darrick J. Wong <djwong@kernel.org> wrote: > > On Fri, Jun 17, 2022 at 01:06:30PM +0300, Amir Goldstein wrote: > > Hi all, > > > > Previously posted candidates for 5.10.y followed chronological release > > order. > > > > Parts 1 and 2 of fixes from v5.10..v5.12 have already been applied to > > v5.10.121. > > > > Part 3 (from 5.13) has already been posted for review [3] on June 6, > > but following feedback from Dave, I changed my focus to get the same > > set of patches tested and reviewed for 5.10.y/5.15.y. > > > > I do want to ask you guys to also find time to review part 3, because > > we have a lot of catching up to do for 5.10.y, so we need to chew at > > this debt at a reasonable rate. > > > > This post has the matching set of patches for 5.10.y that goes with > > Leah's first set of candidates for 5.15.y [1]. > > > > Most of the fixes are from v5.15..v5.17 except for patch 11 (v5.18-rc1). > > All fix patches have been tagged with Fixes: by the author. > > > > The patches have been soaking in kdepops since Sunday. They passed more > > than 30 auto group runs with several different versions of xfsprogs. > > > > The differences from Leah's 5.15.y: > > - It is 11 patches and not 8 because of dependencies > > - Patches 6,7 are non-fixes backported as dependency to patch 8 - > > they have "backported .* for dependency" in their commit message > > - Patches 3,4,11 needed changes to apply to 5.10.y - they have a > > "backport" related comment in their commit message to explain what > > changes were needed > > - Patch 10 is a fix from v5.12 that is re-posted as a dependency for > > patch 11 > > > > Darrick, > > > > As the author patches 4,11 and sole reviewer of patch 3 (a.k.a > > the non-cleanly applied patches), please take a closer look at those. > > > > Patch 10 has been dropped from my part 2 candidates following concerns > > raised by Dave and is now being re-posted following feedback from > > Christian and Christoph [2]. > > > > If there are still concerns about patches 10 or 11, please raise a flag. > > I can drop either of these patches before posting to stable if anyone > > feels that they need more time to soak in master. > > At the current moment (keep in mind that I have 2,978 more emails to get Oh boy! Thank you for getting to my series so soon. > through before I'm caught up), I think it's safe to say that for patches > 1-5: > > Acked-by: Darrick J. Wong <djwong@kernel.org> > > (patch 9 also, but see the reply I just sent for that one about grabbing > the sync_fs fixes too) > > The log changes are going to take more time to go through, since that > stuff is always tricky and /not/ something for me to be messing with at > 4:45pm. Let's make it easier for you then. I already decided to defer patches 9-11. Since you already started looking at patches 6-8, if you want to finish that review let me know and I will wait, but if you prefer, I can also defer the log changes 6-8 and post them along with the other log fixes from 5.14. That means that I have a 5 patch series ACKed and ready to go to stable. Let me know what you prefer. Thanks, Amir.
On Thu, Jun 23, 2022 at 10:33:47AM +0300, Amir Goldstein wrote: > On Thu, Jun 23, 2022 at 2:45 AM Darrick J. Wong <djwong@kernel.org> wrote: > > > > On Fri, Jun 17, 2022 at 01:06:30PM +0300, Amir Goldstein wrote: > > > Hi all, > > > > > > Previously posted candidates for 5.10.y followed chronological release > > > order. > > > > > > Parts 1 and 2 of fixes from v5.10..v5.12 have already been applied to > > > v5.10.121. > > > > > > Part 3 (from 5.13) has already been posted for review [3] on June 6, > > > but following feedback from Dave, I changed my focus to get the same > > > set of patches tested and reviewed for 5.10.y/5.15.y. > > > > > > I do want to ask you guys to also find time to review part 3, because > > > we have a lot of catching up to do for 5.10.y, so we need to chew at > > > this debt at a reasonable rate. > > > > > > This post has the matching set of patches for 5.10.y that goes with > > > Leah's first set of candidates for 5.15.y [1]. > > > > > > Most of the fixes are from v5.15..v5.17 except for patch 11 (v5.18-rc1). > > > All fix patches have been tagged with Fixes: by the author. > > > > > > The patches have been soaking in kdepops since Sunday. They passed more > > > than 30 auto group runs with several different versions of xfsprogs. > > > > > > The differences from Leah's 5.15.y: > > > - It is 11 patches and not 8 because of dependencies > > > - Patches 6,7 are non-fixes backported as dependency to patch 8 - > > > they have "backported .* for dependency" in their commit message > > > - Patches 3,4,11 needed changes to apply to 5.10.y - they have a > > > "backport" related comment in their commit message to explain what > > > changes were needed > > > - Patch 10 is a fix from v5.12 that is re-posted as a dependency for > > > patch 11 > > > > > > Darrick, > > > > > > As the author patches 4,11 and sole reviewer of patch 3 (a.k.a > > > the non-cleanly applied patches), please take a closer look at those. > > > > > > Patch 10 has been dropped from my part 2 candidates following concerns > > > raised by Dave and is now being re-posted following feedback from > > > Christian and Christoph [2]. > > > > > > If there are still concerns about patches 10 or 11, please raise a flag. > > > I can drop either of these patches before posting to stable if anyone > > > feels that they need more time to soak in master. > > > > At the current moment (keep in mind that I have 2,978 more emails to get > > Oh boy! Thank you for getting to my series so soon. > > > through before I'm caught up), I think it's safe to say that for patches > > 1-5: > > > > Acked-by: Darrick J. Wong <djwong@kernel.org> > > > > (patch 9 also, but see the reply I just sent for that one about grabbing > > the sync_fs fixes too) > > > > The log changes are going to take more time to go through, since that > > stuff is always tricky and /not/ something for me to be messing with at > > 4:45pm. > > Let's make it easier for you then. > I already decided to defer patches 9-11. > > Since you already started looking at patches 6-8, if you want to finish > that review let me know and I will wait, but if you prefer, I can also defer > the log changes 6-8 and post them along with the other log fixes from 5.14. > That means that I have a 5 patch series ACKed and ready to go to stable. > > Let me know what you prefer. I wouldn't hold back on sending 1-5 to stable; yesterday was quick triage of the list traffic to figure out who I could unblock most rapidly. --D > Thanks, > Amir.
On Thu, Jun 23, 2022 at 6:05 PM Darrick J. Wong <djwong@kernel.org> wrote: > > On Thu, Jun 23, 2022 at 10:33:47AM +0300, Amir Goldstein wrote: > > On Thu, Jun 23, 2022 at 2:45 AM Darrick J. Wong <djwong@kernel.org> wrote: > > > > > > On Fri, Jun 17, 2022 at 01:06:30PM +0300, Amir Goldstein wrote: > > > > Hi all, > > > > > > > > Previously posted candidates for 5.10.y followed chronological release > > > > order. > > > > > > > > Parts 1 and 2 of fixes from v5.10..v5.12 have already been applied to > > > > v5.10.121. > > > > > > > > Part 3 (from 5.13) has already been posted for review [3] on June 6, > > > > but following feedback from Dave, I changed my focus to get the same > > > > set of patches tested and reviewed for 5.10.y/5.15.y. > > > > > > > > I do want to ask you guys to also find time to review part 3, because > > > > we have a lot of catching up to do for 5.10.y, so we need to chew at > > > > this debt at a reasonable rate. > > > > > > > > This post has the matching set of patches for 5.10.y that goes with > > > > Leah's first set of candidates for 5.15.y [1]. > > > > > > > > Most of the fixes are from v5.15..v5.17 except for patch 11 (v5.18-rc1). > > > > All fix patches have been tagged with Fixes: by the author. > > > > > > > > The patches have been soaking in kdepops since Sunday. They passed more > > > > than 30 auto group runs with several different versions of xfsprogs. > > > > > > > > The differences from Leah's 5.15.y: > > > > - It is 11 patches and not 8 because of dependencies > > > > - Patches 6,7 are non-fixes backported as dependency to patch 8 - > > > > they have "backported .* for dependency" in their commit message > > > > - Patches 3,4,11 needed changes to apply to 5.10.y - they have a > > > > "backport" related comment in their commit message to explain what > > > > changes were needed > > > > - Patch 10 is a fix from v5.12 that is re-posted as a dependency for > > > > patch 11 > > > > > > > > Darrick, > > > > > > > > As the author patches 4,11 and sole reviewer of patch 3 (a.k.a > > > > the non-cleanly applied patches), please take a closer look at those. > > > > > > > > Patch 10 has been dropped from my part 2 candidates following concerns > > > > raised by Dave and is now being re-posted following feedback from > > > > Christian and Christoph [2]. > > > > > > > > If there are still concerns about patches 10 or 11, please raise a flag. > > > > I can drop either of these patches before posting to stable if anyone > > > > feels that they need more time to soak in master. > > > > > > At the current moment (keep in mind that I have 2,978 more emails to get > > > > Oh boy! Thank you for getting to my series so soon. > > > > > through before I'm caught up), I think it's safe to say that for patches > > > 1-5: > > > > > > Acked-by: Darrick J. Wong <djwong@kernel.org> > > > > > > (patch 9 also, but see the reply I just sent for that one about grabbing > > > the sync_fs fixes too) > > > > > > The log changes are going to take more time to go through, since that > > > stuff is always tricky and /not/ something for me to be messing with at > > > 4:45pm. > > > > Let's make it easier for you then. > > I already decided to defer patches 9-11. > > > > Since you already started looking at patches 6-8, if you want to finish > > that review let me know and I will wait, but if you prefer, I can also defer > > the log changes 6-8 and post them along with the other log fixes from 5.14. Hi Darrick, FYI, I started testing the log fixes backports from v5.14 along with the deferred patches 6-8 [1] with extra focus on recoveryloop tests. I know that Leah is also testing another batch of 5.15-only patches, so she may yet post another 5.15-only series before my 5.10-only series. In the meanwhile, if you have some spare time due to rc8, please try to look at the already posted patches 6-8 [2] that were deferred from the original stable submission per your request. Thanks, Amir. [1] https://github.com/amir73il/linux/commits/xfs-5.10.y-for-review [2] https://lore.kernel.org/linux-xfs/20220617100641.1653164-1-amir73il@gmail.com/
On Sun, Jul 24, 2022 at 10:36:15AM +0200, Amir Goldstein wrote: > On Thu, Jun 23, 2022 at 6:05 PM Darrick J. Wong <djwong@kernel.org> wrote: > > > > On Thu, Jun 23, 2022 at 10:33:47AM +0300, Amir Goldstein wrote: > > > On Thu, Jun 23, 2022 at 2:45 AM Darrick J. Wong <djwong@kernel.org> wrote: > > > > > > > > On Fri, Jun 17, 2022 at 01:06:30PM +0300, Amir Goldstein wrote: > > > > > Hi all, > > > > > > > > > > Previously posted candidates for 5.10.y followed chronological release > > > > > order. > > > > > > > > > > Parts 1 and 2 of fixes from v5.10..v5.12 have already been applied to > > > > > v5.10.121. > > > > > > > > > > Part 3 (from 5.13) has already been posted for review [3] on June 6, > > > > > but following feedback from Dave, I changed my focus to get the same > > > > > set of patches tested and reviewed for 5.10.y/5.15.y. > > > > > > > > > > I do want to ask you guys to also find time to review part 3, because > > > > > we have a lot of catching up to do for 5.10.y, so we need to chew at > > > > > this debt at a reasonable rate. > > > > > > > > > > This post has the matching set of patches for 5.10.y that goes with > > > > > Leah's first set of candidates for 5.15.y [1]. > > > > > > > > > > Most of the fixes are from v5.15..v5.17 except for patch 11 (v5.18-rc1). > > > > > All fix patches have been tagged with Fixes: by the author. > > > > > > > > > > The patches have been soaking in kdepops since Sunday. They passed more > > > > > than 30 auto group runs with several different versions of xfsprogs. > > > > > > > > > > The differences from Leah's 5.15.y: > > > > > - It is 11 patches and not 8 because of dependencies > > > > > - Patches 6,7 are non-fixes backported as dependency to patch 8 - > > > > > they have "backported .* for dependency" in their commit message > > > > > - Patches 3,4,11 needed changes to apply to 5.10.y - they have a > > > > > "backport" related comment in their commit message to explain what > > > > > changes were needed > > > > > - Patch 10 is a fix from v5.12 that is re-posted as a dependency for > > > > > patch 11 > > > > > > > > > > Darrick, > > > > > > > > > > As the author patches 4,11 and sole reviewer of patch 3 (a.k.a > > > > > the non-cleanly applied patches), please take a closer look at those. > > > > > > > > > > Patch 10 has been dropped from my part 2 candidates following concerns > > > > > raised by Dave and is now being re-posted following feedback from > > > > > Christian and Christoph [2]. > > > > > > > > > > If there are still concerns about patches 10 or 11, please raise a flag. > > > > > I can drop either of these patches before posting to stable if anyone > > > > > feels that they need more time to soak in master. > > > > > > > > At the current moment (keep in mind that I have 2,978 more emails to get > > > > > > Oh boy! Thank you for getting to my series so soon. > > > > > > > through before I'm caught up), I think it's safe to say that for patches > > > > 1-5: > > > > > > > > Acked-by: Darrick J. Wong <djwong@kernel.org> > > > > > > > > (patch 9 also, but see the reply I just sent for that one about grabbing > > > > the sync_fs fixes too) > > > > > > > > The log changes are going to take more time to go through, since that > > > > stuff is always tricky and /not/ something for me to be messing with at > > > > 4:45pm. > > > > > > Let's make it easier for you then. > > > I already decided to defer patches 9-11. > > > > > > Since you already started looking at patches 6-8, if you want to finish > > > that review let me know and I will wait, but if you prefer, I can also defer > > > the log changes 6-8 and post them along with the other log fixes from 5.14. > > Hi Darrick, > > FYI, I started testing the log fixes backports from v5.14 along with > the deferred > patches 6-8 [1] with extra focus on recoveryloop tests. > > I know that Leah is also testing another batch of 5.15-only patches, so she > may yet post another 5.15-only series before my 5.10-only series. > > In the meanwhile, if you have some spare time due to rc8, please try to > look at the already posted patches 6-8 [2] that were deferred from the original > stable submission per your request. This is pretty difficult request -- while I /think/ the LSN->CSN conversion for the upper layers in patch 7 is correct, I'm not as familiar with where 5.10 is right now as I was when that series was being proposed for upstream. It /looks/ ok, but were I maintaining the 5.10 tree I'd be a lot more comfortable if I had in hand all the results from running the long-soak log recovery tests for a week. (Which itself might be fairly difficult for 5.10...) --D > Thanks, > Amir. > > [1] https://github.com/amir73il/linux/commits/xfs-5.10.y-for-review > [2] https://lore.kernel.org/linux-xfs/20220617100641.1653164-1-amir73il@gmail.com/
> > Hi Darrick, > > > > FYI, I started testing the log fixes backports from v5.14 along with > > the deferred > > patches 6-8 [1] with extra focus on recoveryloop tests. > > > > I know that Leah is also testing another batch of 5.15-only patches, so she > > may yet post another 5.15-only series before my 5.10-only series. > > > > In the meanwhile, if you have some spare time due to rc8, please try to > > look at the already posted patches 6-8 [2] that were deferred from the original > > stable submission per your request. > > This is pretty difficult request -- while I /think/ the LSN->CSN > conversion for the upper layers in patch 7 is correct, I'm not as > familiar with where 5.10 is right now as I was when that series was > being proposed for upstream. > > It /looks/ ok, but were I maintaining the 5.10 tree I'd be a lot more > comfortable if I had in hand all the results from running the long-soak > log recovery tests for a week. Sure, I can do that. > > (Which itself might be fairly difficult for 5.10...) That depends on the exact definition of running the long-soak and log recovery tests for a week. I did run the 'recoveryloop' group 100 times on baseline vs. backports and saw no regressions observed. Also ran 'auto' 10 times and 'soak' 10 times (and counting) with no regressions so far. However, some recoveryloop tests are failing in baseline, so running them "for a week" is meaningless for those tests: generic/019, generic/475, generic/648: failing often in all config generic/388: failing often with reflink_1024 generic/388: failing at ~1/50 rate for any config generic/482: failing often on V4 configs generic/482: failing at ~1/100 rate for V5 configs xfs/057: failing at ~1/200 rate for any config Note that some of those recoverloop tests may be failing due to older xfs_repair [*]. The following recoveryloop/soak tests have NOT failed so far: generic,455, generic/457, generic/646 generic/521, generic/522, generic/642 Should I just keep running those for a week? Another option is to declare those fixes too risky for LTS 5.10. That is always an option we need to consider. Anyway, I will post the full v5.14 series for review and continue running the long soak tests and the passing tests. Thanks, Amir. [*] I should note that the 5.10.y tests are run with xfsprogs 5.10 When I started testing 5.10.y, I used debian/testing with newer xfsprogs but that led to many issues compared to debain/bullseye with xfsprogs 5.10. I figured that it is not very likely for a distro to use kernel 5.10 and much newer xfsprogs (?) so I preferred to test more aligned versions for kernel/xfsprogs to match the real life use cases.