From: Greg Kroah-Hartman Date: Fri, 2 Sep 2022 06:31:26 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.9.327~12 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=95f64ea20eeb5aa8df72b56378c7c3d2d8d7a3eb;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: xfs-always-succeed-at-setting-the-reserve-pool-size.patch xfs-fix-overfilling-of-reserve-pool.patch xfs-fix-soft-lockup-via-spinning-in-filestream-ag-selection-loop.patch xfs-remove-infinite-loop-when-reserving-free-block-pool.patch xfs-revert-xfs-actually-bump-warning-counts-when-we-send-warnings.patch --- diff --git a/queue-5.10/series b/queue-5.10/series index 3d1839da826..5ee3fbf71cc 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -28,3 +28,8 @@ netfilter-conntrack-nf_conntrack_procfs-should-no-lo.patch lib-vdso-mark-do_hres_timens-and-do_coarse_timens-__.patch kprobes-don-t-call-disarm_kprobe-for-disabled-kprobes.patch io_uring-disable-polling-pollfree-files.patch +xfs-remove-infinite-loop-when-reserving-free-block-pool.patch +xfs-always-succeed-at-setting-the-reserve-pool-size.patch +xfs-fix-overfilling-of-reserve-pool.patch +xfs-fix-soft-lockup-via-spinning-in-filestream-ag-selection-loop.patch +xfs-revert-xfs-actually-bump-warning-counts-when-we-send-warnings.patch diff --git a/queue-5.10/xfs-always-succeed-at-setting-the-reserve-pool-size.patch b/queue-5.10/xfs-always-succeed-at-setting-the-reserve-pool-size.patch new file mode 100644 index 00000000000..df7f5c0e2a7 --- /dev/null +++ b/queue-5.10/xfs-always-succeed-at-setting-the-reserve-pool-size.patch @@ -0,0 +1,57 @@ +From foo@baz Fri Sep 2 08:15:14 AM CEST 2022 +From: Amir Goldstein +Date: Thu, 1 Sep 2022 16:33:53 +0300 +Subject: xfs: always succeed at setting the reserve pool size +To: Greg Kroah-Hartman +Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner +Message-ID: <20220901133356.2473299-3-amir73il@gmail.com> + +From: "Darrick J. Wong" + +commit 0baa2657dc4d79202148be79a3dc36c35f425060 upstream. + +Nowadays, xfs_mod_fdblocks will always choose to fill the reserve pool +with freed blocks before adding to fdblocks. Therefore, we can change +the behavior of xfs_reserve_blocks slightly -- setting the target size +of the pool should always succeed, since a deficiency will eventually +be made up as blocks get freed. + +Signed-off-by: Darrick J. Wong +Reviewed-by: Dave Chinner +Signed-off-by: Amir Goldstein +Acked-by: Darrick J. Wong +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_fsops.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/fs/xfs/xfs_fsops.c ++++ b/fs/xfs/xfs_fsops.c +@@ -380,11 +380,14 @@ xfs_reserve_blocks( + * The code below estimates how many blocks it can request from + * fdblocks to stash in the reserve pool. This is a classic TOCTOU + * race since fdblocks updates are not always coordinated via +- * m_sb_lock. ++ * m_sb_lock. Set the reserve size even if there's not enough free ++ * space to fill it because mod_fdblocks will refill an undersized ++ * reserve when it can. + */ + free = percpu_counter_sum(&mp->m_fdblocks) - + xfs_fdblocks_unavailable(mp); + delta = request - mp->m_resblks; ++ mp->m_resblks = request; + if (delta > 0 && free > 0) { + /* + * We'll either succeed in getting space from the free block +@@ -401,10 +404,8 @@ xfs_reserve_blocks( + * Update the reserve counters if blocks have been successfully + * allocated. + */ +- if (!error) { +- mp->m_resblks += fdblks_delta; ++ if (!error) + mp->m_resblks_avail += fdblks_delta; +- } + } + out: + if (outval) { diff --git a/queue-5.10/xfs-fix-overfilling-of-reserve-pool.patch b/queue-5.10/xfs-fix-overfilling-of-reserve-pool.patch new file mode 100644 index 00000000000..643b93dee51 --- /dev/null +++ b/queue-5.10/xfs-fix-overfilling-of-reserve-pool.patch @@ -0,0 +1,57 @@ +From foo@baz Fri Sep 2 08:15:14 AM CEST 2022 +From: Amir Goldstein +Date: Thu, 1 Sep 2022 16:33:54 +0300 +Subject: xfs: fix overfilling of reserve pool +To: Greg Kroah-Hartman +Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner +Message-ID: <20220901133356.2473299-4-amir73il@gmail.com> + +From: "Darrick J. Wong" + +commit 82be38bcf8a2e056b4c99ce79a3827fa743df6ec upstream. + +Due to cycling of m_sb_lock, it's possible for multiple callers of +xfs_reserve_blocks to race at changing the pool size, subtracting blocks +from fdblocks, and actually putting it in the pool. The result of all +this is that we can overfill the reserve pool to hilarious levels. + +xfs_mod_fdblocks, when called with a positive value, already knows how +to take freed blocks and either fill the reserve until it's full, or put +them in fdblocks. Use that instead of setting m_resblks_avail directly. + +Signed-off-by: Darrick J. Wong +Reviewed-by: Dave Chinner +Signed-off-by: Amir Goldstein +Acked-by: Darrick J. Wong +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_fsops.c | 13 ++++++------- + 1 file changed, 6 insertions(+), 7 deletions(-) + +--- a/fs/xfs/xfs_fsops.c ++++ b/fs/xfs/xfs_fsops.c +@@ -394,18 +394,17 @@ xfs_reserve_blocks( + * count or we'll get an ENOSPC. Don't set the reserved flag + * here - we don't want to reserve the extra reserve blocks + * from the reserve. ++ * ++ * The desired reserve size can change after we drop the lock. ++ * Use mod_fdblocks to put the space into the reserve or into ++ * fdblocks as appropriate. + */ + fdblks_delta = min(free, delta); + spin_unlock(&mp->m_sb_lock); + error = xfs_mod_fdblocks(mp, -fdblks_delta, 0); +- spin_lock(&mp->m_sb_lock); +- +- /* +- * Update the reserve counters if blocks have been successfully +- * allocated. +- */ + if (!error) +- mp->m_resblks_avail += fdblks_delta; ++ xfs_mod_fdblocks(mp, fdblks_delta, 0); ++ spin_lock(&mp->m_sb_lock); + } + out: + if (outval) { diff --git a/queue-5.10/xfs-fix-soft-lockup-via-spinning-in-filestream-ag-selection-loop.patch b/queue-5.10/xfs-fix-soft-lockup-via-spinning-in-filestream-ag-selection-loop.patch new file mode 100644 index 00000000000..89ab8e3b6fd --- /dev/null +++ b/queue-5.10/xfs-fix-soft-lockup-via-spinning-in-filestream-ag-selection-loop.patch @@ -0,0 +1,59 @@ +From foo@baz Fri Sep 2 08:15:14 AM CEST 2022 +From: Amir Goldstein +Date: Thu, 1 Sep 2022 16:33:55 +0300 +Subject: xfs: fix soft lockup via spinning in filestream ag selection loop +To: Greg Kroah-Hartman +Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Brian Foster , Christoph Hellwig , Dave Chinner +Message-ID: <20220901133356.2473299-5-amir73il@gmail.com> + +From: Brian Foster + +commit f650df7171b882dca737ddbbeb414100b31f16af upstream. + +The filestream AG selection loop uses pagf data to aid in AG +selection, which depends on pagf initialization. If the in-core +structure is not initialized, the caller invokes the AGF read path +to do so and carries on. If another task enters the loop and finds +a pagf init already in progress, the AGF read returns -EAGAIN and +the task continues the loop. This does not increment the current ag +index, however, which means the task spins on the current AGF buffer +until unlocked. + +If the AGF read I/O submitted by the initial task happens to be +delayed for whatever reason, this results in soft lockup warnings +via the spinning task. This is reproduced by xfs/170. To avoid this +problem, fix the AGF trylock failure path to properly iterate to the +next AG. If a task iterates all AGs without making progress, the +trylock behavior is dropped in favor of blocking locks and thus a +soft lockup is no longer possible. + +Fixes: f48e2df8a877ca1c ("xfs: make xfs_*read_agf return EAGAIN to ALLOC_FLAG_TRYLOCK callers") +Signed-off-by: Brian Foster +Reviewed-by: Darrick J. Wong +Reviewed-by: Christoph Hellwig +Signed-off-by: Dave Chinner +Signed-off-by: Amir Goldstein +Acked-by: Darrick J. Wong +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_filestream.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/fs/xfs/xfs_filestream.c ++++ b/fs/xfs/xfs_filestream.c +@@ -128,11 +128,12 @@ xfs_filestream_pick_ag( + if (!pag->pagf_init) { + err = xfs_alloc_pagf_init(mp, NULL, ag, trylock); + if (err) { +- xfs_perag_put(pag); +- if (err != -EAGAIN) ++ if (err != -EAGAIN) { ++ xfs_perag_put(pag); + return err; ++ } + /* Couldn't lock the AGF, skip this AG. */ +- continue; ++ goto next_ag; + } + } + diff --git a/queue-5.10/xfs-remove-infinite-loop-when-reserving-free-block-pool.patch b/queue-5.10/xfs-remove-infinite-loop-when-reserving-free-block-pool.patch new file mode 100644 index 00000000000..c817e81dd4c --- /dev/null +++ b/queue-5.10/xfs-remove-infinite-loop-when-reserving-free-block-pool.patch @@ -0,0 +1,117 @@ +From foo@baz Fri Sep 2 08:15:14 AM CEST 2022 +From: Amir Goldstein +Date: Thu, 1 Sep 2022 16:33:52 +0300 +Subject: xfs: remove infinite loop when reserving free block pool +To: Greg Kroah-Hartman +Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner +Message-ID: <20220901133356.2473299-2-amir73il@gmail.com> + +From: Darrick J. Wong + +commit 15f04fdc75aaaa1cccb0b8b3af1be290e118a7bc upstream. + +[Added wrapper xfs_fdblocks_unavailable() for 5.10.y backport] + +Infinite loops in kernel code are scary. Calls to xfs_reserve_blocks +should be rare (people should just use the defaults!) so we really don't +need to try so hard. Simplify the logic here by removing the infinite +loop. + +Cc: Brian Foster +Signed-off-by: Darrick J. Wong +Reviewed-by: Dave Chinner +Signed-off-by: Amir Goldstein +Acked-by: Darrick J. Wong +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_fsops.c | 52 +++++++++++++++++++++------------------------------- + fs/xfs/xfs_mount.h | 8 ++++++++ + 2 files changed, 29 insertions(+), 31 deletions(-) + +--- a/fs/xfs/xfs_fsops.c ++++ b/fs/xfs/xfs_fsops.c +@@ -376,46 +376,36 @@ xfs_reserve_blocks( + * If the request is larger than the current reservation, reserve the + * blocks before we update the reserve counters. Sample m_fdblocks and + * perform a partial reservation if the request exceeds free space. ++ * ++ * The code below estimates how many blocks it can request from ++ * fdblocks to stash in the reserve pool. This is a classic TOCTOU ++ * race since fdblocks updates are not always coordinated via ++ * m_sb_lock. + */ +- error = -ENOSPC; +- do { +- free = percpu_counter_sum(&mp->m_fdblocks) - +- mp->m_alloc_set_aside; +- if (free <= 0) +- break; +- +- delta = request - mp->m_resblks; +- lcounter = free - delta; +- if (lcounter < 0) +- /* We can't satisfy the request, just get what we can */ +- fdblks_delta = free; +- else +- fdblks_delta = delta; +- ++ free = percpu_counter_sum(&mp->m_fdblocks) - ++ xfs_fdblocks_unavailable(mp); ++ delta = request - mp->m_resblks; ++ if (delta > 0 && free > 0) { + /* + * We'll either succeed in getting space from the free block +- * count or we'll get an ENOSPC. If we get a ENOSPC, it means +- * things changed while we were calculating fdblks_delta and so +- * we should try again to see if there is anything left to +- * reserve. +- * +- * Don't set the reserved flag here - we don't want to reserve +- * the extra reserve blocks from the reserve..... ++ * count or we'll get an ENOSPC. Don't set the reserved flag ++ * here - we don't want to reserve the extra reserve blocks ++ * from the reserve. + */ ++ fdblks_delta = min(free, delta); + spin_unlock(&mp->m_sb_lock); + error = xfs_mod_fdblocks(mp, -fdblks_delta, 0); + spin_lock(&mp->m_sb_lock); +- } while (error == -ENOSPC); + +- /* +- * Update the reserve counters if blocks have been successfully +- * allocated. +- */ +- if (!error && fdblks_delta) { +- mp->m_resblks += fdblks_delta; +- mp->m_resblks_avail += fdblks_delta; ++ /* ++ * Update the reserve counters if blocks have been successfully ++ * allocated. ++ */ ++ if (!error) { ++ mp->m_resblks += fdblks_delta; ++ mp->m_resblks_avail += fdblks_delta; ++ } + } +- + out: + if (outval) { + outval->resblks = mp->m_resblks; +--- a/fs/xfs/xfs_mount.h ++++ b/fs/xfs/xfs_mount.h +@@ -406,6 +406,14 @@ extern int xfs_initialize_perag(xfs_moun + xfs_agnumber_t *maxagi); + extern void xfs_unmountfs(xfs_mount_t *); + ++/* Accessor added for 5.10.y backport */ ++static inline uint64_t ++xfs_fdblocks_unavailable( ++ struct xfs_mount *mp) ++{ ++ return mp->m_alloc_set_aside; ++} ++ + extern int xfs_mod_fdblocks(struct xfs_mount *mp, int64_t delta, + bool reserved); + extern int xfs_mod_frextents(struct xfs_mount *mp, int64_t delta); diff --git a/queue-5.10/xfs-revert-xfs-actually-bump-warning-counts-when-we-send-warnings.patch b/queue-5.10/xfs-revert-xfs-actually-bump-warning-counts-when-we-send-warnings.patch new file mode 100644 index 00000000000..0b3b696724c --- /dev/null +++ b/queue-5.10/xfs-revert-xfs-actually-bump-warning-counts-when-we-send-warnings.patch @@ -0,0 +1,54 @@ +From foo@baz Fri Sep 2 08:15:14 AM CEST 2022 +From: Amir Goldstein +Date: Thu, 1 Sep 2022 16:33:56 +0300 +Subject: xfs: revert "xfs: actually bump warning counts when we send warnings" +To: Greg Kroah-Hartman +Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Eric Sandeen , Dave Chinner , Dave Chinner +Message-ID: <20220901133356.2473299-6-amir73il@gmail.com> + +From: Eric Sandeen + +commit bc37e4fb5cac2925b2e286b1f1d4fc2b519f7d92 upstream. + +This reverts commit 4b8628d57b725b32616965e66975fcdebe008fe7. + +XFS quota has had the concept of a "quota warning limit" since +the earliest Irix implementation, but a mechanism for incrementing +the warning counter was never implemented, as documented in the +xfs_quota(8) man page. We do know from the historical archive that +it was never incremented at runtime during quota reservation +operations. + +With this commit, the warning counter quickly increments for every +allocation attempt after the user has crossed a quote soft +limit threshold, and this in turn transitions the user to hard +quota failures, rendering soft quota thresholds and timers useless. +This was reported as a regression by users. + +Because the intended behavior of this warning counter has never been +understood or documented, and the result of this change is a regression +in soft quota functionality, revert this commit to make soft quota +limits and timers operable again. + +Fixes: 4b8628d57b72 ("xfs: actually bump warning counts when we send warnings) +Signed-off-by: Eric Sandeen +Reviewed-by: Darrick J. Wong +Reviewed-by: Dave Chinner +Signed-off-by: Dave Chinner +Signed-off-by: Amir Goldstein +Acked-by: Darrick J. Wong +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_trans_dquot.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/fs/xfs/xfs_trans_dquot.c ++++ b/fs/xfs/xfs_trans_dquot.c +@@ -615,7 +615,6 @@ xfs_dqresv_check( + return QUOTA_NL_ISOFTLONGWARN; + } + +- res->warnings++; + return QUOTA_NL_ISOFTWARN; + } +