Re: [PATCH 25/45] block: reference struct block_device from struct hd_struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 24, 2020 at 04:18:49PM -0500, Tejun Heo wrote:
> Hello,
> 
> Please see lkml.kernel.org/r/X708BTJ5njtbC2z1@xxxxxxxxxxxxxxx for a few nits
> on the previous version.

Thanks, I've addressed the mapping_set_gfp mask nit and updated the
commit log.  As Jan pointed also pointed out I think we do need the
remove_inode_hash.

> I might be confused but am wondering whether RCU is needed. It's currently
> used to ensure that gendisk is accessible in the blkdev_get path but
> wouldn't it be possible to simply pin gendisk from block_devices? The
> gendisk and hd_structs hold the base refs of the block_devices and in turn
> the block_devices pin the gendisk. When the gendisk gets deleted, it puts
> the base refs of the block devices but stays around while the block devices
> are being accessed.

Yes, that sounds sensible.  I'll take a look.

> Also, would it make sense to separate out lookup_sem removal? I *think* it's
> there to ensure that the same bdev doesn't get associated with old and new
> gendisks at the same time but can't wrap my head around how it works
> exactly. I can see that this may not be needed once the lifetimes of gendisk
> and block_devices are tied together but that may warrant a bit more
> explanation.

Jan added lookup_sem in commit 56c0908c855afbb to prevent a three way
race between del_gendisk and blkdev_open due to the weird bdev vs
gendisk lifetime rules.  None of that can happen with the new lookup
scheme.



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux