similar to: [PATCH v3] virtio-blk: Fix hot-unplug race in remove method

If we reset the virtio-blk device before the requests already dispatched to the virtio-blk driver from the block layer are finised, we will stuck in blk_cleanup_queue() and the remove will fail. blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued before DEAD marking. However it will never success if the device is already stopped. We'll have q->in_flight[] > 0, so

If we reset the virtio-blk device before the requests already dispatched to the virtio-blk driver from the block layer are finised, we will stuck in blk_cleanup_queue() and the remove will fail. blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued before DEAD marking. However it will never success if the device is already stopped. We'll have q->in_flight[] > 0, so

If we reset the virtio-blk device before the requests already dispatched to the virtio-blk driver from the block layer are finised, we will stuck in blk_cleanup_queue() and the remove will fail. blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued before DEAD marking. However it will never success if the device is already stopped. We'll have q->in_flight[] > 0, so

If we reset the virtio-blk device before the requests already dispatched to the virtio-blk driver from the block layer are finised, we will stuck in blk_cleanup_queue() and the remove will fail. blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued before DEAD marking. However it will never success if the device is already stopped. We'll have q->in_flight[] > 0, so

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

When user hot-unplug a disk which is busy serving I/O, __blk_run_queue might be unable to drain all the requests. As a result, the blk_drain_queue() would loop forever and blk_cleanup_queue would not return. So hot-unplug will fail. This patch adds a callback in blk_drain_queue() for low lever driver to abort requests. Currently, this is useful for virtio-blk to do cleanup in hot-unplug. Cc:

When user hot-unplug a disk which is busy serving I/O, __blk_run_queue might be unable to drain all the requests. As a result, the blk_drain_queue() would loop forever and blk_cleanup_queue would not return. So hot-unplug will fail. This patch adds a callback in blk_drain_queue() for low lever driver to abort requests. Currently, this is useful for virtio-blk to do cleanup in hot-unplug. Cc:

Hi, this patch-set tries to solve various hang situations when virtio devices (network or block) are hot-unplugged from a KVM guest. On System z there exists no handshake mechanism between host and guest when a device is hot-unplugged. The device is removed and no further I/O is possible. The guest is notified about the hard removal with a CRW machine check. As per architecture, the host must

Hi, this patch-set tries to solve various hang situations when virtio devices (network or block) are hot-unplugged from a KVM guest. On System z there exists no handshake mechanism between host and guest when a device is hot-unplugged. The device is removed and no further I/O is possible. The guest is notified about the hard removal with a CRW machine check. As per architecture, the host must

On Wed, Nov 27, 2013 at 11:32:39AM +0100, Heinz Graalfs wrote: > Code is added to avoid calling blk_cleanup_queue() when the surprize_removal > flag is set due to a disappeared device. It avoid hangs due to incomplete > requests (e.g. in-flight requests). Such requests must be considered as lost. Ugh. Can't we complete these immediately using detach_unused_buf? If not why? > If

On Wed, Nov 27, 2013 at 11:32:39AM +0100, Heinz Graalfs wrote: > Code is added to avoid calling blk_cleanup_queue() when the surprize_removal > flag is set due to a disappeared device. It avoid hangs due to incomplete > requests (e.g. in-flight requests). Such requests must be considered as lost. Ugh. Can't we complete these immediately using detach_unused_buf? If not why? > If

3.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Asias He <asias at redhat.com> commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream. blk_cleanup_queue() will call blk_drian_queue() to drain all the requests before queue DEAD marking. If we reset the device before blk_cleanup_queue() the drain would fail. 1) if the queue is stopped

3.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Asias He <asias at redhat.com> commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream. blk_cleanup_queue() will call blk_drian_queue() to drain all the requests before queue DEAD marking. If we reset the device before blk_cleanup_queue() the drain would fail. 1) if the queue is stopped

Linux kernel only supports logical block sizes which are power of two, at least 512 bytes and no more that PAGE_SIZE. Check this instead of crashing later on. Note that there is no need to check physical block size since it is only a hint, and virtio-blk already only supports power of two values. Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1664619 Signed-off-by: Maxim Levitsky

Linux kernel only supports logical block sizes which are power of two, at least 512 bytes and no more that PAGE_SIZE. Check this instead of crashing later on. Note that there is no need to check physical block size since it is only a hint, and virtio-blk already only supports power of two values. Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1664619 Signed-off-by: Maxim Levitsky

On 29/01/14 07:31, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 23/01/14 05:51, Rusty Russell wrote: >>> Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >>>> Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. >>> >>> Hi Heinz, >>> >>> I didn't

On 29/01/14 07:31, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 23/01/14 05:51, Rusty Russell wrote: >>> Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >>>> Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. >>> >>> Hi Heinz, >>> >>> I didn't

On Wed, 2020-07-15 at 06:06 -0400, Michael S. Tsirkin wrote: > On Wed, Jul 15, 2020 at 12:55:18PM +0300, Maxim Levitsky wrote: > > Linux kernel only supports logical block sizes which are power of > > two, > > at least 512 bytes and no more that PAGE_SIZE. > > > > Check this instead of crashing later on. > > > > Note that there is no need to check

On Wed, 2020-07-15 at 06:06 -0400, Michael S. Tsirkin wrote: > On Wed, Jul 15, 2020 at 12:55:18PM +0300, Maxim Levitsky wrote: > > Linux kernel only supports logical block sizes which are power of > > two, > > at least 512 bytes and no more that PAGE_SIZE. > > > > Check this instead of crashing later on. > > > > Note that there is no need to check