similar to: [PATCH RFC 0/7] virtio: avoid various hang situations during hot-unplug

Hi, here is an updated patch-set to my v2 RFC virtio: add new notify() callback to virtio_driver This RFC introduces a new virtio_device entry 'surprize_removal' instead of a new 'notify' callback in struct virtio_driver. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost

Hi, here is an updated patch-set to my v2 RFC virtio: add new notify() callback to virtio_driver This RFC introduces a new virtio_device entry 'surprize_removal' instead of a new 'notify' callback in struct virtio_driver. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost

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

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 get a response on my 'break all the virtqueues' patch > series. Could your System Z code work with this? > > Rusty. > > Sorry Rusty,

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 get a response on my 'break all the virtqueues' patch > series. Could your System Z code work with this? > > Rusty. > > Sorry Rusty,

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential

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

Hi, when an active virtio block device is hot-unplugged from a KVM guest, running affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. On System z there exists no handshake mechanism between host and guest when a device

Hi, when an active virtio block device is hot-unplugged from a KVM guest, running affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. On System z there exists no handshake mechanism between host and guest when a device

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 17/12/13 04:42, 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. >> >> When an active virtio block device is hot-unplugged from a KVM guest, >> affected guest user applications are not aware of any errors that occur >> due to the lost device. This

On 17/12/13 04:42, 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. >> >> When an active virtio block device is hot-unplugged from a KVM guest, >> affected guest user applications are not aware of any errors that occur >> due to the lost device. This

On 19/12/13 01:19, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 17/12/13 04:42, 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. >>>> >>>> When an active virtio block device is

On 19/12/13 01:19, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 17/12/13 04:42, 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. >>>> >>>> When an active virtio block device is

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: