From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 0/6] btrfs: use the super_block as bdev holder
Date: Tue, 17 Jun 2025 14:49:33 +0930 [thread overview]
Message-ID: <cover.1750137547.git.wqu@suse.com> (raw)
[CHANGELOG]
v3:
- Drop the btrfs_fs_devices::opened split
It turns out to cause problems during tests.
- Extra cleanup related to the btrfs_get_tree_*()
Now the re-entry through vfs_get_tree() is completely dropped.
- Extra comments explaining the sget_fc() behavior
- Call bdev_fput() instead of fput()
This alignes us to all the other fses.
- Updated patch to delay btrfs_open_devices() until sget_fc()
Instead of relying on the previous solution (split
btrfs_open_devices::opened), just expand the uuid_mutex critical
section.
This is the refreshed series based on the one submitted by Johannes,
which is further based on the original series from Christoph.
This series is to make btrfs use its super block as blk_holder, this
allows future usage of fs_holder_ops to support block device operations.
This is done by:
- Get rid of the re-entry of btrfs_get_tree()
Now it's a simple call chain:
btrfs_get_tree() -> btrfs_get_tree_subvol() -> btrfs_get_tree_super()
- Make it more clear on the sget_fc() behavior
And what should be cleaned up.
- Call btrfs_close_devices() from kill_sb() callback
- Call bdev_fput() instead of deferred fput()
This ensures we won't get some block devices with invalid holder,
while the fs is already closed.
- Delay btrfs_open_devices(0 until super block is created
This is done in a simpler way, just expand the uuid_mutex critical
section to cover sget_fc().
- Use super block as blk_holder
Christoph Hellwig (2):
btrfs: call btrfs_close_devices from ->kill_sb
btrfs: use the super_block as holder when mounting file systems
Qu Wenruo (4):
btrfs: get rid of the re-entry of btrfs_get_tree()
btrfs: add comments to make super block creation more clear
btrfs: call bdev_fput() to reclaim the blk_holder immediately
btrfs: delay btrfs_open_devices() until super block is created
fs/btrfs/dev-replace.c | 4 +-
fs/btrfs/disk-io.c | 4 +-
fs/btrfs/fs.h | 2 -
fs/btrfs/ioctl.c | 4 +-
fs/btrfs/super.c | 96 ++++++++++++++++++------------------------
fs/btrfs/volumes.c | 22 +++++-----
6 files changed, 59 insertions(+), 73 deletions(-)
--
2.49.0
next reply other threads:[~2025-06-17 5:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-17 5:19 Qu Wenruo [this message]
2025-06-17 5:19 ` [PATCH v3 1/6] btrfs: get rid of the re-entry of btrfs_get_tree() Qu Wenruo
2025-06-17 5:19 ` [PATCH v3 2/6] btrfs: add comments to make super block creation more clear Qu Wenruo
2025-06-17 5:19 ` [PATCH v3 3/6] btrfs: call btrfs_close_devices from ->kill_sb Qu Wenruo
2025-06-17 7:01 ` Johannes Thumshirn
2025-06-17 5:19 ` [PATCH v3 4/6] btrfs: call bdev_fput() to reclaim the blk_holder immediately Qu Wenruo
2025-06-17 5:19 ` [PATCH v3 5/6] btrfs: delay btrfs_open_devices() until super block is created Qu Wenruo
2025-06-17 5:19 ` [PATCH v3 6/6] btrfs: use the super_block as holder when mounting file systems Qu Wenruo
2025-06-19 13:29 ` [PATCH v3 0/6] btrfs: use the super_block as bdev holder David Sterba
2025-06-19 23:04 ` Qu Wenruo
2025-06-20 12:18 ` David Sterba
2025-06-23 1:10 ` Qu Wenruo
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=cover.1750137547.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@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