public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Boris Burkov <boris@bur.io>
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>, Christoph Hellwig <hch@lst.de>,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] btrfs: open block devices after superblock creation
Date: Mon, 19 Feb 2024 21:18:24 +0100	[thread overview]
Message-ID: <20240219201824.GA355@twin.jikos.cz> (raw)
In-Reply-To: <20240214185809.GC377066@zen.localdomain>

On Wed, Feb 14, 2024 at 10:58:09AM -0800, Boris Burkov wrote:
> On Wed, Feb 14, 2024 at 08:42:15AM -0800, Johannes Thumshirn wrote:
> > From: Christoph Hellwig <hch@lst.de>
> > 
> > Currently btrfs_mount_root opens the block devices before committing to
> > allocating a super block. That creates problems for restricting the
> > number of writers to a device, and also leads to a unusual and not very
> > helpful holder (the fs_type).
> > 
> > Reorganize the code to first check whether the superblock for a
> > particular fsid does already exist and open the block devices only if it
> > doesn't, mirroring the recent changes to the VFS mount helpers.  To do
> > this the increment of the in_use counter moves out of btrfs_open_devices
> > and into the only caller in btrfs_mount_root so that it happens before
> > dropping uuid_mutex around the call to sget.
> 
> I believe this commit message is now out of date as of
> 'btrfs: remove old mount API code'
> which got rid of btrfs_mount_root.

It's not just that, this patchset was sent before the conversion to new
mount API that changed how devices are scanned (and potentially race
with mount). The changelog should be updated at minimum.

I haven't found any problems so far, the locking around device opening
should serialize any races so the one thread winning will open the super
block and the other will inherit the fs_devices.

  reply	other threads:[~2024-02-19 20:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 16:42 [PATCH 0/5] btrfs: use the super_block as bdev holder Johannes Thumshirn
2024-02-14 16:42 ` [PATCH 1/5] btrfs: always open the device read-only in btrfs_scan_one_device Johannes Thumshirn
2024-02-19 20:22   ` David Sterba
2024-02-14 16:42 ` [PATCH 2/5] btrfs: call btrfs_close_devices from ->kill_sb Johannes Thumshirn
2025-06-10  5:43   ` Qu Wenruo
2024-02-14 16:42 ` [PATCH 3/5] btrfs: split btrfs_fs_devices.opened Johannes Thumshirn
2024-02-14 16:42 ` [PATCH 4/5] btrfs: open block devices after superblock creation Johannes Thumshirn
2024-02-14 18:58   ` Boris Burkov
2024-02-19 20:18     ` David Sterba [this message]
2024-02-14 16:42 ` [PATCH 5/5] btrfs: use the super_block as holder when mounting file systems Johannes Thumshirn
2024-02-14 18:57 ` [PATCH 0/5] btrfs: use the super_block as bdev holder Boris Burkov
2024-02-15  5:04 ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2023-12-18  4:49 Christoph Hellwig
2023-12-18  4:49 ` [PATCH 4/5] btrfs: open block devices after superblock creation Christoph Hellwig

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=20240219201824.GA355@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=boris@bur.io \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@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