From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Long Li <leo.lilong@huawei.com>,
djwong@kernel.org, chandanbabu@kernel.org,
linux-xfs@vger.kernel.org, yi.zhang@huawei.com,
houtao1@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH 1/2] xfs: add lock protection when remove perag from radix tree
Date: Wed, 6 Dec 2023 08:28:00 +1100 [thread overview]
Message-ID: <ZW+V4N5KcBiQa6//@dread.disaster.area> (raw)
In-Reply-To: <ZW6ofJp3zRn/X3Mc@infradead.org>
On Mon, Dec 04, 2023 at 08:35:08PM -0800, Christoph Hellwig wrote:
> On Mon, Dec 04, 2023 at 12:39:10PM +0800, Long Li wrote:
> > Look at the perag insertion into the radix tree, protected by
> > mp->m_perag_lock. When the file system is unmounted, the perag is
> > removed from the radix tree, also protected by mp->m_perag_lock.
> > Therefore, mp->m_perag_lock is also added when removing a perag
> > from the radix tree in error path in xfs_initialize_perag().
>
> There really can't be anything we are racing with at this point.
I'm pretty sure that there can be racing 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...
> That beeing said I think clearing locking rules are always a good
> thing. So maybe reword the above as:
>
> "Take mp->m_perag_lock for deletions from the perag radix tree in
> xfs_initialize_perag to be consistent with additions to it even
> if there can't be concurrent modifications to it at this point"
I don't think it needs even that - just making the radix tree
modifications serialise against each other is obviously correct...
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2023-12-05 21:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 4:39 [PATCH 1/2] xfs: add lock protection when remove perag from radix tree Long Li
2023-12-04 4:39 ` [PATCH 2/2] xfs: fix perag leak when growfs fails Long Li
2023-12-05 4:38 ` Christoph Hellwig
2023-12-06 12:48 ` Long Li
2023-12-05 4:35 ` [PATCH 1/2] xfs: add lock protection when remove perag from radix tree Christoph Hellwig
2023-12-05 21:28 ` Dave Chinner [this message]
2023-12-06 12:32 ` Long Li
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=ZW+V4N5KcBiQa6//@dread.disaster.area \
--to=david@fromorbit.com \
--cc=chandanbabu@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@infradead.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