* [Qemu-devel] [PATCH v2 0/2] virtio-scsi: Fix assertion failure on dataplane handlers @ 2017-03-14 15:36 Fam Zheng 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 1/2] virtio-scsi: Make virtio_scsi_acquire/release public Fam Zheng 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers Fam Zheng 0 siblings, 2 replies; 10+ messages in thread From: Fam Zheng @ 2017-03-14 15:36 UTC (permalink / raw) To: qemu-devel; +Cc: Paolo Bonzini v2: Use virtio_scsi_acquire/release. [Paolo] Fam Zheng (2): virtio-scsi: Make virtio_scsi_acquire/release public virtio-scsi: Fix acquire/release in dataplane handlers hw/scsi/virtio-scsi-dataplane.c | 20 ++++++++++++++++---- hw/scsi/virtio-scsi.c | 40 ++++++++++++++-------------------------- include/hw/virtio/virtio-scsi.h | 14 ++++++++++++++ 3 files changed, 44 insertions(+), 30 deletions(-) -- 2.9.3 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Qemu-devel] [PATCH v2 1/2] virtio-scsi: Make virtio_scsi_acquire/release public 2017-03-14 15:36 [Qemu-devel] [PATCH v2 0/2] virtio-scsi: Fix assertion failure on dataplane handlers Fam Zheng @ 2017-03-14 15:36 ` Fam Zheng 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers Fam Zheng 1 sibling, 0 replies; 10+ messages in thread From: Fam Zheng @ 2017-03-14 15:36 UTC (permalink / raw) To: qemu-devel; +Cc: Paolo Bonzini They will be used in virtio-scsi-dataplane.c as well, so move them to header. Signed-off-by: Fam Zheng <famz@redhat.com> --- hw/scsi/virtio-scsi.c | 14 -------------- include/hw/virtio/virtio-scsi.h | 14 ++++++++++++++ 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index 1dbc4bc..e7466d3 100644 --- a/hw/scsi/virtio-scsi.c +++ b/hw/scsi/virtio-scsi.c @@ -422,20 +422,6 @@ static void virtio_scsi_handle_ctrl_req(VirtIOSCSI *s, VirtIOSCSIReq *req) } } -static inline void virtio_scsi_acquire(VirtIOSCSI *s) -{ - if (s->ctx) { - aio_context_acquire(s->ctx); - } -} - -static inline void virtio_scsi_release(VirtIOSCSI *s) -{ - if (s->ctx) { - aio_context_release(s->ctx); - } -} - bool virtio_scsi_handle_ctrl_vq(VirtIOSCSI *s, VirtQueue *vq) { VirtIOSCSIReq *req; diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h index f536f77..8ae0aca 100644 --- a/include/hw/virtio/virtio-scsi.h +++ b/include/hw/virtio/virtio-scsi.h @@ -121,6 +121,20 @@ typedef struct VirtIOSCSIReq { } req; } VirtIOSCSIReq; +static inline void virtio_scsi_acquire(VirtIOSCSI *s) +{ + if (s->ctx) { + aio_context_acquire(s->ctx); + } +} + +static inline void virtio_scsi_release(VirtIOSCSI *s) +{ + if (s->ctx) { + aio_context_release(s->ctx); + } +} + void virtio_scsi_common_realize(DeviceState *dev, Error **errp, VirtIOHandleOutput ctrl, VirtIOHandleOutput evt, VirtIOHandleOutput cmd); -- 2.9.3 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-14 15:36 [Qemu-devel] [PATCH v2 0/2] virtio-scsi: Fix assertion failure on dataplane handlers Fam Zheng 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 1/2] virtio-scsi: Make virtio_scsi_acquire/release public Fam Zheng @ 2017-03-14 15:36 ` Fam Zheng 2017-03-15 17:25 ` Ed Swierk ` (3 more replies) 1 sibling, 4 replies; 10+ messages in thread From: Fam Zheng @ 2017-03-14 15:36 UTC (permalink / raw) To: qemu-devel; +Cc: Paolo Bonzini After the AioContext lock push down, there is a race between virtio_scsi_dataplane_start and those "assert(s->ctx && s->dataplane_started)", because the latter doesn't isn't wrapped in aio_context_acquire. Reproducer is simply booting a Fedora guest with an empty virtio-scsi-dataplane controller: qemu-system-x86_64 \ -drive if=none,id=root,format=raw,file=Fedora-Cloud-Base-25-1.3.x86_64.raw \ -device virtio-scsi \ -device scsi-disk,drive=root,bootindex=1 \ -object iothread,id=io \ -device virtio-scsi-pci,iothread=io \ -net user,hostfwd=tcp::10022-:22 -net nic,model=virtio -m 2048 \ --enable-kvm Fix this by moving acquire/release pairs from virtio_scsi_handle_*_vq to their callers - and wrap the broken assertions in. Signed-off-by: Fam Zheng <famz@redhat.com> --- hw/scsi/virtio-scsi-dataplane.c | 20 ++++++++++++++++---- hw/scsi/virtio-scsi.c | 26 ++++++++++++++------------ 2 files changed, 30 insertions(+), 16 deletions(-) diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c index 74c95e0..944ea4e 100644 --- a/hw/scsi/virtio-scsi-dataplane.c +++ b/hw/scsi/virtio-scsi-dataplane.c @@ -52,28 +52,40 @@ void virtio_scsi_dataplane_setup(VirtIOSCSI *s, Error **errp) static bool virtio_scsi_data_plane_handle_cmd(VirtIODevice *vdev, VirtQueue *vq) { - VirtIOSCSI *s = (VirtIOSCSI *)vdev; + bool progress; + VirtIOSCSI *s = VIRTIO_SCSI(vdev); + virtio_scsi_acquire(s); assert(s->ctx && s->dataplane_started); - return virtio_scsi_handle_cmd_vq(s, vq); + progress = virtio_scsi_handle_cmd_vq(s, vq); + virtio_scsi_release(s); + return progress; } static bool virtio_scsi_data_plane_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq) { + bool progress; VirtIOSCSI *s = VIRTIO_SCSI(vdev); + virtio_scsi_acquire(s); assert(s->ctx && s->dataplane_started); - return virtio_scsi_handle_ctrl_vq(s, vq); + progress = virtio_scsi_handle_ctrl_vq(s, vq); + virtio_scsi_release(s); + return progress; } static bool virtio_scsi_data_plane_handle_event(VirtIODevice *vdev, VirtQueue *vq) { + bool progress; VirtIOSCSI *s = VIRTIO_SCSI(vdev); + virtio_scsi_acquire(s); assert(s->ctx && s->dataplane_started); - return virtio_scsi_handle_event_vq(s, vq); + progress = virtio_scsi_handle_event_vq(s, vq); + virtio_scsi_release(s); + return progress; } static int virtio_scsi_vring_init(VirtIOSCSI *s, VirtQueue *vq, int n, diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index e7466d3..4939f1f 100644 --- a/hw/scsi/virtio-scsi.c +++ b/hw/scsi/virtio-scsi.c @@ -427,12 +427,10 @@ bool virtio_scsi_handle_ctrl_vq(VirtIOSCSI *s, VirtQueue *vq) VirtIOSCSIReq *req; bool progress = false; - virtio_scsi_acquire(s); while ((req = virtio_scsi_pop_req(s, vq))) { progress = true; virtio_scsi_handle_ctrl_req(s, req); } - virtio_scsi_release(s); return progress; } @@ -446,7 +444,9 @@ static void virtio_scsi_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq) return; } } + virtio_scsi_acquire(s); virtio_scsi_handle_ctrl_vq(s, vq); + virtio_scsi_release(s); } static void virtio_scsi_complete_cmd_req(VirtIOSCSIReq *req) @@ -590,7 +590,6 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq) QTAILQ_HEAD(, VirtIOSCSIReq) reqs = QTAILQ_HEAD_INITIALIZER(reqs); - virtio_scsi_acquire(s); do { virtio_queue_set_notification(vq, 0); @@ -618,7 +617,6 @@ bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq) QTAILQ_FOREACH_SAFE(req, &reqs, next, next) { virtio_scsi_handle_cmd_req_submit(s, req); } - virtio_scsi_release(s); return progress; } @@ -633,7 +631,9 @@ static void virtio_scsi_handle_cmd(VirtIODevice *vdev, VirtQueue *vq) return; } } + virtio_scsi_acquire(s); virtio_scsi_handle_cmd_vq(s, vq); + virtio_scsi_release(s); } static void virtio_scsi_get_config(VirtIODevice *vdev, @@ -709,12 +709,10 @@ void virtio_scsi_push_event(VirtIOSCSI *s, SCSIDevice *dev, return; } - virtio_scsi_acquire(s); - req = virtio_scsi_pop_req(s, vs->event_vq); if (!req) { s->events_dropped = true; - goto out; + return; } if (s->events_dropped) { @@ -724,7 +722,7 @@ void virtio_scsi_push_event(VirtIOSCSI *s, SCSIDevice *dev, if (virtio_scsi_parse_req(req, 0, sizeof(VirtIOSCSIEvent))) { virtio_scsi_bad_req(req); - goto out; + return; } evt = &req->resp.event; @@ -744,19 +742,15 @@ void virtio_scsi_push_event(VirtIOSCSI *s, SCSIDevice *dev, evt->lun[3] = dev->lun & 0xFF; } virtio_scsi_complete_req(req); -out: - virtio_scsi_release(s); } bool virtio_scsi_handle_event_vq(VirtIOSCSI *s, VirtQueue *vq) { - virtio_scsi_acquire(s); if (s->events_dropped) { virtio_scsi_push_event(s, NULL, VIRTIO_SCSI_T_NO_EVENT, 0); virtio_scsi_release(s); return true; } - virtio_scsi_release(s); return false; } @@ -770,7 +764,9 @@ static void virtio_scsi_handle_event(VirtIODevice *vdev, VirtQueue *vq) return; } } + virtio_scsi_acquire(s); virtio_scsi_handle_event_vq(s, vq); + virtio_scsi_release(s); } static void virtio_scsi_change(SCSIBus *bus, SCSIDevice *dev, SCSISense sense) @@ -780,8 +776,10 @@ static void virtio_scsi_change(SCSIBus *bus, SCSIDevice *dev, SCSISense sense) if (virtio_vdev_has_feature(vdev, VIRTIO_SCSI_F_CHANGE) && dev->type != TYPE_ROM) { + virtio_scsi_acquire(s); virtio_scsi_push_event(s, dev, VIRTIO_SCSI_T_PARAM_CHANGE, sense.asc | (sense.ascq << 8)); + virtio_scsi_release(s); } } @@ -803,9 +801,11 @@ static void virtio_scsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, } if (virtio_vdev_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG)) { + virtio_scsi_acquire(s); virtio_scsi_push_event(s, sd, VIRTIO_SCSI_T_TRANSPORT_RESET, VIRTIO_SCSI_EVT_RESET_RESCAN); + virtio_scsi_release(s); } } @@ -817,9 +817,11 @@ static void virtio_scsi_hotunplug(HotplugHandler *hotplug_dev, DeviceState *dev, SCSIDevice *sd = SCSI_DEVICE(dev); if (virtio_vdev_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG)) { + virtio_scsi_acquire(s); virtio_scsi_push_event(s, sd, VIRTIO_SCSI_T_TRANSPORT_RESET, VIRTIO_SCSI_EVT_RESET_REMOVED); + virtio_scsi_release(s); } qdev_simple_device_unplug_cb(hotplug_dev, dev, errp); -- 2.9.3 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers Fam Zheng @ 2017-03-15 17:25 ` Ed Swierk 2017-03-16 1:22 ` Fam Zheng ` (2 subsequent siblings) 3 siblings, 0 replies; 10+ messages in thread From: Ed Swierk @ 2017-03-15 17:25 UTC (permalink / raw) To: Fam Zheng; +Cc: qemu-devel, Paolo Bonzini On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng <famz@redhat.com> wrote: > After the AioContext lock push down, there is a race between > virtio_scsi_dataplane_start and those "assert(s->ctx && > s->dataplane_started)", because the latter doesn't isn't wrapped in > aio_context_acquire. > > Reproducer is simply booting a Fedora guest with an empty > virtio-scsi-dataplane controller: > > qemu-system-x86_64 \ > -drive if=none,id=root,format=raw,file=Fedora-Cloud-Base-25-1.3.x86_64.raw \ > -device virtio-scsi \ > -device scsi-disk,drive=root,bootindex=1 \ > -object iothread,id=io \ > -device virtio-scsi-pci,iothread=io \ > -net user,hostfwd=tcp::10022-:22 -net nic,model=virtio -m 2048 \ > --enable-kvm > > Fix this by moving acquire/release pairs from virtio_scsi_handle_*_vq to > their callers - and wrap the broken assertions in. > > Signed-off-by: Fam Zheng <famz@redhat.com> Verified this fixes the assertion failure on 2.9.0-rc0. Tested-by: Ed Swierk <eswierk@skyportsystems.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers Fam Zheng 2017-03-15 17:25 ` Ed Swierk @ 2017-03-16 1:22 ` Fam Zheng 2017-03-16 23:48 ` Ed Swierk 2017-03-17 0:26 ` Ed Swierk 3 siblings, 0 replies; 10+ messages in thread From: Fam Zheng @ 2017-03-16 1:22 UTC (permalink / raw) To: qemu-devel; +Cc: Paolo Bonzini On Tue, 03/14 23:36, Fam Zheng wrote: > After the AioContext lock push down, there is a race between > virtio_scsi_dataplane_start and those "assert(s->ctx && > s->dataplane_started)", because the latter doesn't isn't wrapped in s/doesn't// > aio_context_acquire. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers Fam Zheng 2017-03-15 17:25 ` Ed Swierk 2017-03-16 1:22 ` Fam Zheng @ 2017-03-16 23:48 ` Ed Swierk 2017-03-17 1:34 ` Fam Zheng 2017-03-17 0:26 ` Ed Swierk 3 siblings, 1 reply; 10+ messages in thread From: Ed Swierk @ 2017-03-16 23:48 UTC (permalink / raw) To: Fam Zheng; +Cc: qemu-devel, Paolo Bonzini On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng <famz@redhat.com> wrote: > diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c > index e7466d3..4939f1f 100644 > --- a/hw/scsi/virtio-scsi.c > +++ b/hw/scsi/virtio-scsi.c > ... > bool virtio_scsi_handle_event_vq(VirtIOSCSI *s, VirtQueue *vq) > { > - virtio_scsi_acquire(s); > if (s->events_dropped) { > virtio_scsi_push_event(s, NULL, VIRTIO_SCSI_T_NO_EVENT, 0); > virtio_scsi_release(s); Did you intend to leave this virtio_scsi_release() call? > return true; > } > - virtio_scsi_release(s); > return false; > } ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-16 23:48 ` Ed Swierk @ 2017-03-17 1:34 ` Fam Zheng 0 siblings, 0 replies; 10+ messages in thread From: Fam Zheng @ 2017-03-17 1:34 UTC (permalink / raw) To: Ed Swierk; +Cc: qemu-devel, Paolo Bonzini On Thu, 03/16 16:48, Ed Swierk wrote: > On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng <famz@redhat.com> wrote: > > diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c > > index e7466d3..4939f1f 100644 > > --- a/hw/scsi/virtio-scsi.c > > +++ b/hw/scsi/virtio-scsi.c > > ... > > bool virtio_scsi_handle_event_vq(VirtIOSCSI *s, VirtQueue *vq) > > { > > - virtio_scsi_acquire(s); > > if (s->events_dropped) { > > virtio_scsi_push_event(s, NULL, VIRTIO_SCSI_T_NO_EVENT, 0); > > virtio_scsi_release(s); > > Did you intend to leave this virtio_scsi_release() call? Oops, no, we should drop it. Fam > > > return true; > > } > > - virtio_scsi_release(s); > > return false; > > } ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers Fam Zheng ` (2 preceding siblings ...) 2017-03-16 23:48 ` Ed Swierk @ 2017-03-17 0:26 ` Ed Swierk 2017-03-17 6:02 ` Fam Zheng 3 siblings, 1 reply; 10+ messages in thread From: Ed Swierk @ 2017-03-17 0:26 UTC (permalink / raw) To: Fam Zheng; +Cc: qemu-devel, Paolo Bonzini On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng <famz@redhat.com> wrote: > After the AioContext lock push down, there is a race between > virtio_scsi_dataplane_start and those "assert(s->ctx && > s->dataplane_started)", because the latter doesn't isn't wrapped in > aio_context_acquire. > > Reproducer is simply booting a Fedora guest with an empty > virtio-scsi-dataplane controller: > > qemu-system-x86_64 \ > -drive if=none,id=root,format=raw,file=Fedora-Cloud-Base-25-1.3.x86_64.raw \ > -device virtio-scsi \ > -device scsi-disk,drive=root,bootindex=1 \ > -object iothread,id=io \ > -device virtio-scsi-pci,iothread=io \ > -net user,hostfwd=tcp::10022-:22 -net nic,model=virtio -m 2048 \ > --enable-kvm > > Fix this by moving acquire/release pairs from virtio_scsi_handle_*_vq to > their callers - and wrap the broken assertions in. > > Signed-off-by: Fam Zheng <famz@redhat.com> With this change on top of 2.9.0-rc0, I am able to boot a Linux guest from a virtio-scsi drive with an iothread, e.g. qemu-system-x86_64 -nographic -enable-kvm -monitor telnet:0.0.0.0:1234,server,nowait -m 1024 -object iothread,id=iothread1 -device virtio-scsi-pci,iothread=iothread1,id=scsi0 -drive file=/x/drive.qcow2,format=qcow2,if=none,id=drive0,cache=directsync,aio=native -device scsi-hd,drive=drive0,bootindex=1 But when I try to take a snapshot by running this in the monitor snapshot_blkdev drive0 /x/snap1.qcow2 qemu bombs with qemu-system-x86_64: /x/qemu/include/block/aio.h:457: aio_enable_external: Assertion `ctx->external_disable_cnt > 0' failed. This does not occur if I don't use the iothread. I instrumented the code a bit, printing the value of bs, bdrv_get_aio_context(bs), and bdrv_get_aio_context(bs)->external_disable_cnt before and after aio_{disable,enable}_external() in bdrv_drained_{begin,end}(). Without the iothread, nested calls to these functions cause the counter to increase and decrease as you'd expect, and the context is the same in each call. bdrv_drained_begin 0 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=0 bdrv_drained_begin 1 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_begin 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_begin 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 bdrv_drained_end 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 bdrv_drained_end 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_begin 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_begin 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 bdrv_drained_end 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 bdrv_drained_end 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_end 0 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=1 bdrv_drained_end 1 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=0 But with the iothread, there are at least two different context pointers, and there is one extra call to bdrv_drained_end() without a matching bdrv_drained_begin(). That last call comes from external_snapshot_clean(). bdrv_drained_begin 0 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=0 bdrv_drained_begin 1 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=1 bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_begin 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_begin 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 bdrv_drained_end 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 bdrv_drained_end 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_begin 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_begin 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 bdrv_drained_end 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 bdrv_drained_end 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe443749a00 cnt=1 bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe443749a00 cnt=0 bdrv_drained_end 0 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=0 qemu-system-x86_64: /x/qemu/include/block/aio.h:457: aio_enable_external: Assertion `ctx->external_disable_cnt > 0' failed. I didn't have much luck bisecting the bug, since about 200 commits prior to 2.9.0-rc0 qemu bombs immediately on boot, and after that I get the assertion addressed by your patch. I have to go farther back to find a working version. Any help would be appreciated. --Ed ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-17 0:26 ` Ed Swierk @ 2017-03-17 6:02 ` Fam Zheng 2017-03-17 6:13 ` Ed Swierk 0 siblings, 1 reply; 10+ messages in thread From: Fam Zheng @ 2017-03-17 6:02 UTC (permalink / raw) To: Ed Swierk; +Cc: Paolo Bonzini, qemu-devel On Thu, 03/16 17:26, Ed Swierk wrote: > On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng <famz@redhat.com> wrote: > > After the AioContext lock push down, there is a race between > > virtio_scsi_dataplane_start and those "assert(s->ctx && > > s->dataplane_started)", because the latter doesn't isn't wrapped in > > aio_context_acquire. > > > > Reproducer is simply booting a Fedora guest with an empty > > virtio-scsi-dataplane controller: > > > > qemu-system-x86_64 \ > > -drive if=none,id=root,format=raw,file=Fedora-Cloud-Base-25-1.3.x86_64.raw \ > > -device virtio-scsi \ > > -device scsi-disk,drive=root,bootindex=1 \ > > -object iothread,id=io \ > > -device virtio-scsi-pci,iothread=io \ > > -net user,hostfwd=tcp::10022-:22 -net nic,model=virtio -m 2048 \ > > --enable-kvm > > > > Fix this by moving acquire/release pairs from virtio_scsi_handle_*_vq to > > their callers - and wrap the broken assertions in. > > > > Signed-off-by: Fam Zheng <famz@redhat.com> > > With this change on top of 2.9.0-rc0, I am able to boot a Linux guest > from a virtio-scsi drive with an iothread, e.g. > > qemu-system-x86_64 -nographic -enable-kvm -monitor > telnet:0.0.0.0:1234,server,nowait -m 1024 -object > iothread,id=iothread1 -device > virtio-scsi-pci,iothread=iothread1,id=scsi0 -drive > file=/x/drive.qcow2,format=qcow2,if=none,id=drive0,cache=directsync,aio=native > -device scsi-hd,drive=drive0,bootindex=1 > > But when I try to take a snapshot by running this in the monitor > > snapshot_blkdev drive0 /x/snap1.qcow2 > > qemu bombs with > > qemu-system-x86_64: /x/qemu/include/block/aio.h:457: > aio_enable_external: Assertion `ctx->external_disable_cnt > 0' failed. > > This does not occur if I don't use the iothread. > > I instrumented the code a bit, printing the value of bs, > bdrv_get_aio_context(bs), and > bdrv_get_aio_context(bs)->external_disable_cnt before and after > aio_{disable,enable}_external() in bdrv_drained_{begin,end}(). > > Without the iothread, nested calls to these functions cause the > counter to increase and decrease as you'd expect, and the context is > the same in each call. > > bdrv_drained_begin 0 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=0 > > But with the iothread, there are at least two different context > pointers, and there is one extra call to bdrv_drained_end() without a > matching bdrv_drained_begin(). That last call comes from > external_snapshot_clean(). > > bdrv_drained_begin 0 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=0 > bdrv_drained_begin 1 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=1 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe443749a00 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe443749a00 cnt=0 > bdrv_drained_end 0 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=0 > qemu-system-x86_64: /x/qemu/include/block/aio.h:457: > aio_enable_external: Assertion `ctx->external_disable_cnt > 0' failed. This may indeed come from the left-behind virtio_scsi_release() you pointed out, I'll fix it in v3 and please see if it helps. Fam ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers 2017-03-17 6:02 ` Fam Zheng @ 2017-03-17 6:13 ` Ed Swierk 0 siblings, 0 replies; 10+ messages in thread From: Ed Swierk @ 2017-03-17 6:13 UTC (permalink / raw) To: Fam Zheng; +Cc: qemu-devel, Paolo Bonzini On Mar 16, 2017 23:02, "Fam Zheng" <famz@redhat.com> wrote: On Thu, 03/16 17:26, Ed Swierk wrote: > On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng <famz@redhat.com> wrote: > > After the AioContext lock push down, there is a race between > > virtio_scsi_dataplane_start and those "assert(s->ctx && > > s->dataplane_started)", because the latter doesn't isn't wrapped in > > aio_context_acquire. > > > > Reproducer is simply booting a Fedora guest with an empty > > virtio-scsi-dataplane controller: > > > > qemu-system-x86_64 \ > > -drive if=none,id=root,format=raw,file=Fedora-Cloud-Base-25-1.3.x86_64.raw \ > > -device virtio-scsi \ > > -device scsi-disk,drive=root,bootindex=1 \ > > -object iothread,id=io \ > > -device virtio-scsi-pci,iothread=io \ > > -net user,hostfwd=tcp::10022-:22 -net nic,model=virtio -m 2048 \ > > --enable-kvm > > > > Fix this by moving acquire/release pairs from virtio_scsi_handle_*_vq to > > their callers - and wrap the broken assertions in. > > > > Signed-off-by: Fam Zheng <famz@redhat.com> > > With this change on top of 2.9.0-rc0, I am able to boot a Linux guest > from a virtio-scsi drive with an iothread, e.g. > > qemu-system-x86_64 -nographic -enable-kvm -monitor > telnet:0.0.0.0:1234,server,nowait -m 1024 -object > iothread,id=iothread1 -device > virtio-scsi-pci,iothread=iothread1,id=scsi0 -drive > file=/x/drive.qcow2,format=qcow2,if=none,id=drive0,cache= directsync,aio=native > -device scsi-hd,drive=drive0,bootindex=1 > > But when I try to take a snapshot by running this in the monitor > > snapshot_blkdev drive0 /x/snap1.qcow2 > > qemu bombs with > > qemu-system-x86_64: /x/qemu/include/block/aio.h:457: > aio_enable_external: Assertion `ctx->external_disable_cnt > 0' failed. > > This does not occur if I don't use the iothread. > > I instrumented the code a bit, printing the value of bs, > bdrv_get_aio_context(bs), and > bdrv_get_aio_context(bs)->external_disable_cnt before and after > aio_{disable,enable}_external() in bdrv_drained_{begin,end}(). > > Without the iothread, nested calls to these functions cause the > counter to increase and decrease as you'd expect, and the context is > the same in each call. > > bdrv_drained_begin 0 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_begin 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 0 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=3 > bdrv_drained_end 1 bs=0x7fe9f67cfde0 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe9f5d12a00 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe9f5ad65a0 ctx=0x7fe9f5abc7b0 cnt=0 > > But with the iothread, there are at least two different context > pointers, and there is one extra call to bdrv_drained_end() without a > matching bdrv_drained_begin(). That last call comes from > external_snapshot_clean(). > > bdrv_drained_begin 0 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=0 > bdrv_drained_begin 1 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=1 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_begin 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 0 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=2 > bdrv_drained_end 1 bs=0x7fe44444de20 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 0 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=0 > bdrv_drained_begin 1 bs=0x7fe443990a00 ctx=0x7fe44373a7b0 cnt=1 > bdrv_drained_end 0 bs=0x7fe443990a00 ctx=0x7fe443749a00 cnt=1 > bdrv_drained_end 1 bs=0x7fe443990a00 ctx=0x7fe443749a00 cnt=0 > bdrv_drained_end 0 bs=0x7fe4437545c0 ctx=0x7fe443749a00 cnt=0 > qemu-system-x86_64: /x/qemu/include/block/aio.h:457: > aio_enable_external: Assertion `ctx->external_disable_cnt > 0' failed. This may indeed come from the left-behind virtio_scsi_release() you pointed out, I'll fix it in v3 and please see if it helps. Fam I tried that, but the 'ctx->external_disable_cnt > 0' assertion still occurs. --Ed ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-03-17 6:13 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-03-14 15:36 [Qemu-devel] [PATCH v2 0/2] virtio-scsi: Fix assertion failure on dataplane handlers Fam Zheng 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 1/2] virtio-scsi: Make virtio_scsi_acquire/release public Fam Zheng 2017-03-14 15:36 ` [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers Fam Zheng 2017-03-15 17:25 ` Ed Swierk 2017-03-16 1:22 ` Fam Zheng 2017-03-16 23:48 ` Ed Swierk 2017-03-17 1:34 ` Fam Zheng 2017-03-17 0:26 ` Ed Swierk 2017-03-17 6:02 ` Fam Zheng 2017-03-17 6:13 ` Ed Swierk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).