Heinz Graalfs <graalfs@xxxxxxxxxxxxxxxxxx> writes: > Code is added to the remove callback to verify if a device was lost. > > In case of a device loss further request queueing should be prevented > by setting appropriate queue flags prior to invoking del_gendisk(). > Blocking of request queueing leads to appropriate I/O errors when data > are tried to be synched. Trying to synch data to a lost block device > doesn't make too much sense. Sure, but this isn't the only case where we should set these flags, right? I would think if any virtqueue is reported broken, we should mark the queue dying too. > If the current remove callback was triggered due to an unregister driver, > and the surprize_removal is not already set (although the actual device > is already gone, e.g. virsh detach), del_gendisk() would be triggered > resulting in a hang. This is a weird situation, and most likely not > 'serializable'. This seems like abusing the vdev struct to pass an argument to virtblk_remove(). How about you mark all virtqueues broken in the "unexpected removal" case? Then the driver should correctly fail to deliver requests. Cheers, Rusty. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
