Hello! On Tue 24-11-20 11:59:49, Tejun Heo wrote: > > diff --git a/block/partitions/core.c b/block/partitions/core.c > > index a02e224115943d..0ba0bf44b88af3 100644 > > --- a/block/partitions/core.c > > +++ b/block/partitions/core.c > > @@ -340,12 +340,11 @@ void delete_partition(struct hd_struct *part) > > device_del(part_to_dev(part)); > > > > /* > > - * Remove gendisk pointer from idr so that it cannot be looked up > > - * while RCU period before freeing gendisk is running to prevent > > - * use-after-free issues. Note that the device number stays > > - * "in-use" until we really free the gendisk. > > + * Remove the block device from the inode hash, so that it cannot be > > + * looked up while waiting for the RCU grace period. > > */ > > - blk_invalidate_devt(part_devt(part)); > > + remove_inode_hash(part->bdev->bd_inode); > > I don't think this is necessary now that the bdev and inode lifetimes are > one. Before, punching out the association early was necessary because we > could be in a situation where we can successfully look up a part from idr > and then try to pin the associated disk which may already be freed. With the > new code, the lookup is through the inode whose lifetime is one and the same > with gendisk, so use-after-free isn't possible and __blkdev_get() will > reliably reject such open attempts. I think the remove_inode_hash() call is actually still needed. Consider a situation when the disk is unplugged, gendisk gets destroyed, bdev still lives on (e.g. because it is still open). Device gets re-plugged, gendisk for the same device number gets created. But we really need new bdev for this because from higher level POV this is completely new device. And the old bdev needs to live on as long as it is open. So IMO we still need to just unhash the inode and leave it lingering in the background. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
