public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, linux-xfs@vger.kernel.org,
	Long Li <leo.lilong@huawei.com>, Christoph Hellwig <hch@lst.de>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Chandan Babu R <chandanbabu@kernel.org>,
	Catherine Hoang <catherine.hoang@oracle.com>
Subject: [PATCH 6.6 271/396] xfs: add lock protection when remove perag from radix tree
Date: Mon,  1 Apr 2024 17:45:20 +0200	[thread overview]
Message-ID: <20240401152555.992420168@linuxfoundation.org> (raw)
In-Reply-To: <20240401152547.867452742@linuxfoundation.org>

6.6-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Long Li <leo.lilong@huawei.com>

commit 07afd3173d0c6d24a47441839a835955ec6cf0d4 upstream.

Take mp->m_perag_lock for deletions from the perag radix tree in
xfs_initialize_perag to prevent racing with tagging operations.
Lookups are fine - they are RCU protected so already deal with the
tree changing shape underneath the lookup - but tagging operations
require the tree to be stable while the tags are propagated back up
to the root.

Right now there's nothing stopping radix tree tagging from operating
while a growfs operation is progress and adding/removing new entries
into the radix tree.

Hence we can have traversals that require a stable tree occurring at
the same time we are removing unused entries from the radix tree which
causes the shape of the tree to change.

Likely this hasn't caused a problem in the past because we are only
doing append addition and removal so the active AG part of the tree
is not changing shape, but that doesn't mean it is safe. Just making
the radix tree modifications serialise against each other is obviously
correct.

Signed-off-by: Long Li <leo.lilong@huawei.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/xfs/libxfs/xfs_ag.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/fs/xfs/libxfs/xfs_ag.c
+++ b/fs/xfs/libxfs/xfs_ag.c
@@ -424,13 +424,17 @@ xfs_initialize_perag(
 
 out_remove_pag:
 	xfs_defer_drain_free(&pag->pag_intents_drain);
+	spin_lock(&mp->m_perag_lock);
 	radix_tree_delete(&mp->m_perag_tree, index);
+	spin_unlock(&mp->m_perag_lock);
 out_free_pag:
 	kmem_free(pag);
 out_unwind_new_pags:
 	/* unwind any prior newly initialized pags */
 	for (index = first_initialised; index < agcount; index++) {
+		spin_lock(&mp->m_perag_lock);
 		pag = radix_tree_delete(&mp->m_perag_tree, index);
+		spin_unlock(&mp->m_perag_lock);
 		if (!pag)
 			break;
 		xfs_buf_hash_destroy(pag);



  parent reply	other threads:[~2024-04-01 16:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240401152547.867452742@linuxfoundation.org>
2024-04-01 15:45 ` [PATCH 6.6 253/396] xfs: move the xfs_rtbitmap.c declarations to xfs_rtbitmap.h Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 254/396] xfs: convert rt bitmap extent lengths to xfs_rtbxlen_t Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 255/396] xfs: consider minlen sized extents in xfs_rtallocate_extent_block Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 256/396] xfs: dont leak recovered attri intent items Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 257/396] xfs: use xfs_defer_pending objects to recover " Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 258/396] xfs: pass the xfs_defer_pending object to iop_recover Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 259/396] xfs: transfer recovered intent item ownership in ->iop_recover Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 260/396] xfs: make rextslog computation consistent with mkfs Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 261/396] xfs: fix 32-bit truncation in xfs_compute_rextslog Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 262/396] xfs: dont allow overly small or large realtime volumes Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 263/396] xfs: make xchk_iget safer in the presence of corrupt inode btrees Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 264/396] xfs: remove unused fields from struct xbtree_ifakeroot Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 265/396] xfs: recompute growfsrtfree transaction reservation while growing rt volume Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 266/396] xfs: fix an off-by-one error in xreap_agextent_binval Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 267/396] xfs: force all buffers to be written during btree bulk load Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 268/396] xfs: add missing nrext64 inode flag check to scrub Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 269/396] xfs: initialise di_crc in xfs_log_dinode Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 270/396] xfs: short circuit xfs_growfs_data_private() if delta is zero Greg Kroah-Hartman
2024-04-01 15:45 ` Greg Kroah-Hartman [this message]
2024-04-01 15:45 ` [PATCH 6.6 272/396] xfs: fix perag leak when growfs fails Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 273/396] xfs: ensure logflagsp is initialized in xfs_bmap_del_extent_real Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 274/396] xfs: update dir3 leaf block metadata after swap Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 275/396] xfs: reset XFS_ATTR_INCOMPLETE filter on node removal Greg Kroah-Hartman
2024-04-01 15:45 ` [PATCH 6.6 276/396] xfs: remove conditional building of rt geometry validator functions Greg Kroah-Hartman

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=20240401152555.992420168@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=catherine.hoang@oracle.com \
    --cc=chandanbabu@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=leo.lilong@huawei.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --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