search for: virtblk_remov

...> > [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 > > [<ffffffff8d488771>] block_ioctl+0x41/0x50 > > [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 > > [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 > > > > A related problem is that virtblk_remove() leaks the vd_index_ida index > > when something still holds a reference to vblk->disk during hot unplug. > > This causes virtio-blk device names to be lost (vda, vdb, etc). > > > > Fix these issues by protecting vblk->vdev with a mutex and reference > > count...

...> > [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 > > [<ffffffff8d488771>] block_ioctl+0x41/0x50 > > [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 > > [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 > > > > A related problem is that virtblk_remove() leaks the vd_index_ida index > > when something still holds a reference to vblk->disk during hot unplug. > > This causes virtio-blk device names to be lost (vda, vdb, etc). > > > > Fix these issues by protecting vblk->vdev with a mutex and reference > > count...

...e covers both virtio_driver probe/remove and block_device_operations open/release users. This ensures that block_device_operations functions like virtblk_getgeo() can safely access struct virtio_blk. Add remove_mutex to prevent block_device_operations functions from accessing vblk->vdev during virtblk_remove() and let the safely check for !vblk->vdev after virtblk_remove() returns. Switching to a reference count also solves the vd_index_ida leak where vda, vdb, vdc, etc indices were lost when the device was hot unplugged while the block device was still open. Reported-by: Lance Digby <ldigby a...

...e covers both virtio_driver probe/remove and block_device_operations open/release users. This ensures that block_device_operations functions like virtblk_getgeo() can safely access struct virtio_blk. Add remove_mutex to prevent block_device_operations functions from accessing vblk->vdev during virtblk_remove() and let the safely check for !vblk->vdev after virtblk_remove() returns. Switching to a reference count also solves the vd_index_ida leak where vda, vdb, vdc, etc indices were lost when the device was hot unplugged while the block device was still open. Reported-by: Lance Digby <ldigby a...

...tl(HDIO_GETGEO) after hot > > unplug to invoke virtblk_getgeo(). > > > which causes what? a use after free? Yes, use after free. I will include the kernel panic in the next revision. virtio_check_driver_offered_feature() accesses vdev->dev.driver, which doesn't work after virtblk_remove() has freed vdev :). > > > > Introduce a reference count in struct virtio_blk so that its lifetime > > covers both virtio_driver probe/remove and block_device_operations > > open/release users. This ensures that block_device_operations functions > > like virtblk_ge...

...[<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc). Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed...

...[<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc). Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed...

...block device is hot-unplugged. Several different errors occur when a block device with mounted file-system(s) is hot-unplugged. Asynchronous writeback functions, as well as page cache read or write operations end up in never ending wait situations. Hang situations occur during device removal when virtblk_remove() invokes del_gendisk() to synch dirty inode pages (invalidate_partition()). The below patches [4,5,6,7] also exploit a 'broken' virtqueue in order to trigger IO errors as well as to prevent final hanging IO operations. Heinz Graalfs (7): virtio_ring: add new functions virtqueue{_set_...

...block device is hot-unplugged. Several different errors occur when a block device with mounted file-system(s) is hot-unplugged. Asynchronous writeback functions, as well as page cache read or write operations end up in never ending wait situations. Hang situations occur during device removal when virtblk_remove() invokes del_gendisk() to synch dirty inode pages (invalidate_partition()). The below patches [4,5,6,7] also exploit a 'broken' virtqueue in order to trigger IO errors as well as to prevent final hanging IO operations. Heinz Graalfs (7): virtio_ring: add new functions virtqueue{_set_...

...ff8d561265>] blkdev_ioctl+0x1f5/0xa20 > > > [<ffffffff8d488771>] block_ioctl+0x41/0x50 > > > [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 > > > [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 > > > > > > A related problem is that virtblk_remove() leaks the vd_index_ida index > > > when something still holds a reference to vblk->disk during hot unplug. > > > This causes virtio-blk device names to be lost (vda, vdb, etc). > > > > > > Fix these issues by protecting vblk->vdev with a mutex and refer...

...[<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc). Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed...

...[<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc). Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed...

A virtio_blk block device can still be referenced after hot unplug by userspace processes that hold the file descriptor. In this case virtblk_getgeo() can be invoked after virtblk_remove() was called. For example, a program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot unplug. Fix this by clearing vblk->disk->private_data and checking that the virtio_blk driver instance is still around in virtblk_getgeo(). Note that the virtblk_getgeo() function itself is g...

A virtio_blk block device can still be referenced after hot unplug by userspace processes that hold the file descriptor. In this case virtblk_getgeo() can be invoked after virtblk_remove() was called. For example, a program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot unplug. Fix this by clearing vblk->disk->private_data and checking that the virtio_blk driver instance is still around in virtblk_getgeo(). Note that the virtblk_getgeo() function itself is g...

...er probe/remove and block_device_operations > open/release users. This ensures that block_device_operations functions > like virtblk_getgeo() can safely access struct virtio_blk. > > Add remove_mutex to prevent block_device_operations functions from > accessing vblk->vdev during virtblk_remove() and let the safely check let the -> let them? > for !vblk->vdev after virtblk_remove() returns. > > Switching to a reference count also solves the vd_index_ida leak where > vda, vdb, vdc, etc indices were lost when the device was hot unplugged > while the block device was...

...? handle_mm_fault+0x39d/0x9b0 > [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 > [<ffffffff8d488771>] block_ioctl+0x41/0x50 > [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 > [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 > > A related problem is that virtblk_remove() leaks the vd_index_ida index > when something still holds a reference to vblk->disk during hot unplug. > This causes virtio-blk device names to be lost (vda, vdb, etc). > > Fix these issues by protecting vblk->vdev with a mutex and reference > counting vblk so the vd_index_...

This patch set fixes the race when hot-unplug stressed disk. Asias He (3): virtio-blk: Call del_gendisk() before disable guest kick virtio-blk: Reset device after blk_cleanup_queue() virtio-blk: Use block layer provided spinlock drivers/block/virtio_blk.c | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) -- 1.7.10.2

This patch set fixes the race when hot-unplug stressed disk. Asias He (3): virtio-blk: Call del_gendisk() before disable guest kick virtio-blk: Reset device after blk_cleanup_queue() virtio-blk: Use block layer provided spinlock drivers/block/virtio_blk.c | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) -- 1.7.10.2

...[<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc). Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed...

...[<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc). Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed...