linux-kernel - Re: [PATCH 1/5] btrfs: always open the device read-only in btrfs_scan_one

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 19 Feb 2024 21:22:47 +0100
From: David Sterba <dsterba@...e.cz>
To: Johannes Thumshirn <johannes.thumshirn@....com>
Cc: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
	David Sterba <dsterba@...e.com>, Christoph Hellwig <hch@....de>,
	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] btrfs: always open the device read-only in
 btrfs_scan_one_device

On Wed, Feb 14, 2024 at 08:42:12AM -0800, Johannes Thumshirn wrote:
> From: Christoph Hellwig <hch@....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);