public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Long Li <leo.lilong@huawei.com>
Cc: chandanbabu@kernel.org, linux-xfs@vger.kernel.org,
	yi.zhang@huawei.com, houtao1@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH v3 1/2] xfs: add lock protection when remove perag from radix tree
Date: Wed, 13 Dec 2023 10:18:49 -0800	[thread overview]
Message-ID: <20231213181849.GI361584@frogsfrogsfrogs> (raw)
In-Reply-To: <20231213031013.390145-1-leo.lilong@huawei.com>

On Wed, Dec 13, 2023 at 11:10:12AM +0800, Long Li wrote:
> 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>

Looks correct to me, and I didn't find any other suspicious accesses of
m_perag_tree so

Reviewed-by: Darrick J. Wong <djwong@kernel.org>

--D

> ---
>  fs/xfs/libxfs/xfs_ag.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/fs/xfs/libxfs/xfs_ag.c b/fs/xfs/libxfs/xfs_ag.c
> index f62ff125a50a..c730976fdfc0 100644
> --- 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);
> -- 
> 2.31.1
> 
> 

      parent reply	other threads:[~2023-12-13 18:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13  3:10 [PATCH v3 1/2] xfs: add lock protection when remove perag from radix tree Long Li
2023-12-13  3:10 ` [PATCH v3 2/2] xfs: fix perag leak when growfs fails Long Li
2023-12-13 18:21   ` Darrick J. Wong
2023-12-14  2:13     ` Long Li
2023-12-13 18:18 ` Darrick J. Wong [this message]

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=20231213181849.GI361584@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=chandanbabu@kernel.org \
    --cc=houtao1@huawei.com \
    --cc=leo.lilong@huawei.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    /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