| Message ID | 20230712094733.1265038-1-amir73il@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | xfs inodegc fixes for 6.1.y (from v6.4) | expand |
On Wed, Jul 12, 2023 at 12:47:30PM +0300, Amir Goldstein wrote: > Darrick, > > These are the patches we discussed that Leah requested for the 5.15.y > backport of non-blocking inodegc pushes series [1]. > > They may or may not help the 5.15.y -> 6.1.y regression that was > reported by Chris [2]. > > Note that I did not include: > 2d5f38a31980 ("xfs: disable reaping in fscounters scrub") > in this backport set, because I generally do not want to deal with > backporting fixes for experimental features. I don't agree with this decision because the comment for xfs_inodegc_stop now says that callers must hold s_umount. xchk_stop_reaping definitely does /not/ hold that lock, which means it's now buggy. Someone downstream could be using scrub, even if it's still experimental. I've generally said not to bother with scrub fixes, but I don't think it's correct to introduce a bug in an LTS kernel. Please backport 2d5f38a31980 since all it does is removes the offending call and turns off code in fscounters.c. --D > This series has gone through the usual kdevops testing routine. > > Please ACK. > > Thanks, > Amir. > > [1] https://www.spinics.net/lists/linux-xfs/msg61813.html > [2] https://lore.kernel.org/all/ZK4E%2FgGuaBu+qvKL@dread.disaster.area/ > > Darrick J. Wong (3): > xfs: explicitly specify cpu when forcing inodegc delayed work to run > immediately > xfs: check that per-cpu inodegc workers actually run on that cpu > xfs: fix xfs_inodegc_stop racing with mod_delayed_work > > fs/xfs/xfs_icache.c | 40 +++++++++++++++++++++++++++++++++------- > fs/xfs/xfs_mount.h | 3 +++ > fs/xfs/xfs_super.c | 3 +++ > 3 files changed, 39 insertions(+), 7 deletions(-) > > -- > 2.34.1 >
On Wed, Jul 12, 2023 at 6:44 PM Darrick J. Wong <djwong@kernel.org> wrote: > > On Wed, Jul 12, 2023 at 12:47:30PM +0300, Amir Goldstein wrote: > > Darrick, > > > > These are the patches we discussed that Leah requested for the 5.15.y > > backport of non-blocking inodegc pushes series [1]. > > > > They may or may not help the 5.15.y -> 6.1.y regression that was > > reported by Chris [2]. > > > > Note that I did not include: > > 2d5f38a31980 ("xfs: disable reaping in fscounters scrub") > > in this backport set, because I generally do not want to deal with > > backporting fixes for experimental features. > > I don't agree with this decision because the comment for > xfs_inodegc_stop now says that callers must hold s_umount. > xchk_stop_reaping definitely does /not/ hold that lock, which means it's > now buggy. Someone downstream could be using scrub, even if it's still > experimental. > > I've generally said not to bother with scrub fixes, but I don't think > it's correct to introduce a bug in an LTS kernel. Please backport > 2d5f38a31980 since all it does is removes the offending call and turns > off code in fscounters.c. > Makes sense. Will do. Thanks, Amir.
Darrick, These are the patches we discussed that Leah requested for the 5.15.y backport of non-blocking inodegc pushes series [1]. They may or may not help the 5.15.y -> 6.1.y regression that was reported by Chris [2]. Note that I did not include: 2d5f38a31980 ("xfs: disable reaping in fscounters scrub") in this backport set, because I generally do not want to deal with backporting fixes for experimental features. This series has gone through the usual kdevops testing routine. Please ACK. Thanks, Amir. [1] https://www.spinics.net/lists/linux-xfs/msg61813.html [2] https://lore.kernel.org/all/ZK4E%2FgGuaBu+qvKL@dread.disaster.area/ Darrick J. Wong (3): xfs: explicitly specify cpu when forcing inodegc delayed work to run immediately xfs: check that per-cpu inodegc workers actually run on that cpu xfs: fix xfs_inodegc_stop racing with mod_delayed_work fs/xfs/xfs_icache.c | 40 +++++++++++++++++++++++++++++++++------- fs/xfs/xfs_mount.h | 3 +++ fs/xfs/xfs_super.c | 3 +++ 3 files changed, 39 insertions(+), 7 deletions(-)