On Tue, Jan 09, 2024 at 09:46:27AM +0100, Jan Kara wrote: > On Mon 08-01-24 17:26:41, Christoph Hellwig wrote: > > On Wed, Jan 03, 2024 at 01:54:58PM +0100, Christian Brauner wrote: > > > I wanted to see whether we can make struct bdev_handle completely > > > private to the block layer in the next cycle and unexport low-level > > > helpers such as bdev_release() - formerly blkdev_put() - completely. > > > > I think we can actually kill bdev_handle entirely. We can get the > > bdev from the bdev inode using I_BDEV already, so no need to store > > the bdev. We don't need the mode field as we known an exlusive > > open is equivalent to having a holder. So just store the older in > > file->private_data and the bdev_handle can be removed again. > > Well, we also need the read-write mode of the handle in some places but that > could be stored in file->f_mode (not sure if it really gets stored there > in this patch set - still need to read the details) so in principle I agree > that bdev_handle should not be necessary. So I think I've found a way to not even use a new fmode flag for this. We can just use a set of file operations def_blk_fops_restricted to detect when a block device was opened with restricted write access. def_blk_fops isn't needed to check whether something is a block device IS_BLK() is enough for that. And def_blk_fops_restricted can be kept completely local to block/.
