Received-SPF: pass (google.com: domain of linux-kernel+bounces-71958-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 19 Feb 2024 21:22:47 +0100
From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Cc: 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 1/5] btrfs: always open the device read-only in
 btrfs_scan_one_device
Message-ID: <20240219202247.GB355@twin.jikos.cz>
Reply-To: dsterba@suse.cz
References: <20240214-hch-device-open-v1-0-b153428b4f72@wdc.com>
 <20240214-hch-device-open-v1-1-b153428b4f72@wdc.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240214-hch-device-open-v1-1-b153428b4f72@wdc.com>
User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12)

On Wed, Feb 14, 2024 at 08:42:12AM -0800, Johannes Thumshirn wrote:
> From: Christoph Hellwig <hch@lst.de>
> 
> btrfs_scan_one_device opens the block device only to read the super
> block.  Instead of passing a blk_mode_t argument to sometimes open
> it for writing, just hard code BLK_OPEN_READ as it will never write
> to the device or hand the block_device out to someone else.

Opening for write was not meant to be for writing but also to exclude
other attempted writes.

That it's always for read seems OK, this has changed at some point and
is explained in btrfs_scan_one_device():

1356         /*
1357          * Avoid an exclusive open here, as the systemd-udev may initiate the 
1358          * device scan which may race with the user's mount or mkfs command,  
1359          * resulting in failure.                                              
1360          * Since the device scan is solely for reading purposes, there is no   
1361          * need for an exclusive open. Additionally, the devices are read again
1362          * during the mount process. It is ok to get some inconsistent    
1363          * values temporarily, as the device paths of the fsid are the only
1364          * required information for assembling the volume.
1365          */
1366         bdev_handle = bdev_open_by_path(path, flags, NULL, NULL);