linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Leah Rumancik <leah.rumancik@gmail.com>,
	Chandan Babu R <chandan.babu@oracle.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Adam Manzanares <a.manzanares@samsung.com>,
	linux-xfs@vger.kernel.org, stable@vger.kernel.org,
	Dave Chinner <dchinner@redhat.com>
Subject: [PATCH 5.10 v2 2/7] xfs: always succeed at setting the reserve pool size
Date: Thu,  1 Sep 2022 08:48:49 +0300	[thread overview]
Message-ID: <20220901054854.2449416-3-amir73il@gmail.com> (raw)
In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com>

From: "Darrick J. Wong" <djwong@kernel.org>

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 <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
---
 fs/xfs/xfs_fsops.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index 6d4f4271e7be..dacead0d0934 100644
--- 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) {
-- 
2.25.1


  parent reply	other threads:[~2022-09-01  5:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01  5:48 [PATCH 5.10 v2 0/7] xfs stable patches for 5.10.y (from v5.18+) Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 1/7] xfs: remove infinite loop when reserving free block pool Amir Goldstein
2022-09-01  5:48 ` Amir Goldstein [this message]
2022-09-01  5:48 ` [PATCH 5.10 v2 3/7] xfs: fix overfilling of reserve pool Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 4/7] xfs: fix soft lockup via spinning in filestream ag selection loop Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 5/7] xfs: revert "xfs: actually bump warning counts when we send warnings" Amir Goldstein
2022-09-01  5:48 ` [PATCH 5.10 v2 6/7] xfs: reorder iunlink remove operation in xfs_ifree Amir Goldstein
2022-09-01  9:04   ` Frank Hofmann
2022-09-01  9:30     ` Amir Goldstein
2022-09-01  9:41       ` Greg Kroah-Hartman
2022-09-01 10:16         ` Amir Goldstein
2022-09-01 10:26           ` Greg Kroah-Hartman
2022-09-01 12:37             ` Amir Goldstein
2022-09-01 13:07               ` Greg Kroah-Hartman
2022-09-01 15:19                 ` Amir Goldstein
2022-09-01 11:43       ` Frank Hofmann
2022-09-01  5:48 ` [PATCH 5.10 v2 7/7] xfs: validate inode fork size against fork format Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220901054854.2449416-3-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=a.manzanares@samsung.com \
    --cc=chandan.babu@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=leah.rumancik@gmail.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).