search for: __blk_end_request_all

...calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. > > Hi Jens, pls see below - it looks like the call to blk_mq_end_io > from IRQ context is causing the issue. > IIUC you switched virtio to this from __blk_end_request_all in > > commit 1cf7e9c68fe84248174e998922b39e508375e7c1 > virtio_blk: blk-mq support > > Is this always safe? > I note that at least one other driver is doing this: > drivers/block/mtip32xx/mtip32xx.c Just like __blk_end_request_all blk_mq_end_io is supposed to be called...

...calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. > > Hi Jens, pls see below - it looks like the call to blk_mq_end_io > from IRQ context is causing the issue. > IIUC you switched virtio to this from __blk_end_request_all in > > commit 1cf7e9c68fe84248174e998922b39e508375e7c1 > virtio_blk: blk-mq support > > Is this always safe? > I note that at least one other driver is doing this: > drivers/block/mtip32xx/mtip32xx.c Just like __blk_end_request_all blk_mq_end_io is supposed to be called...

...nish. How to reproduce the race: 1. hot-plug a virtio-blk device 2. keep reading/writing the device in guest 3. hot-unplug while the device is busy serving I/O Test: ~1000 rounds of hot-plug/hot-unplug test passed with this patch. Changes in v3: - Drop blk_abort_queue and blk_abort_request - Use __blk_end_request_all to complete request dispatched to driver Changes in v2: - Drop req_in_flight - Use virtqueue_detach_unused_buf to get request dispatched to driver Signed-off-by: Asias He <asias at redhat.com> --- drivers/block/virtio_blk.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a...

...nish. How to reproduce the race: 1. hot-plug a virtio-blk device 2. keep reading/writing the device in guest 3. hot-unplug while the device is busy serving I/O Test: ~1000 rounds of hot-plug/hot-unplug test passed with this patch. Changes in v3: - Drop blk_abort_queue and blk_abort_request - Use __blk_end_request_all to complete request dispatched to driver Changes in v2: - Drop req_in_flight - Use virtqueue_detach_unused_buf to get request dispatched to driver Signed-off-by: Asias He <asias at redhat.com> --- drivers/block/virtio_blk.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a...

...on from an invalid context. The > > > backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. > > > > Hi Jens, pls see below - it looks like the call to blk_mq_end_io > > from IRQ context is causing the issue. > > IIUC you switched virtio to this from __blk_end_request_all in > > > > commit 1cf7e9c68fe84248174e998922b39e508375e7c1 > > virtio_blk: blk-mq support > > > > Is this always safe? > > I note that at least one other driver is doing this: > > drivers/block/mtip32xx/mtip32xx.c > > Just like __blk_end_reques...

This is fairly simple: we create a request pointing at the 1k kmalloc, then just change the type so our do_req() knows to mark it as a GET_ID for the server. Seems to work here; the only issue is that the error didn't get passed back from __blk_end_request_all to blk_execute_rq, so we set ->errors to 1 on error. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Jens Axboe <axboe at kernel.dk> --- drivers/block/virtio_blk.c | 66 +++++++++++++++++++++++++++++++++++---------- include/linux/virtio_blk.h | 4 ++ 2 files change...

This is fairly simple: we create a request pointing at the 1k kmalloc, then just change the type so our do_req() knows to mark it as a GET_ID for the server. Seems to work here; the only issue is that the error didn't get passed back from __blk_end_request_all to blk_execute_rq, so we set ->errors to 1 on error. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Jens Axboe <axboe at kernel.dk> --- drivers/block/virtio_blk.c | 66 +++++++++++++++++++++++++++++++++++---------- include/linux/virtio_blk.h | 4 ++ 2 files change...

.../* Process context for config space updates */ @@ -55,7 +52,6 @@ struct virtio_blk struct virtblk_req { - struct list_head list; struct request *req; struct virtio_blk_outhdr out_hdr; struct virtio_scsi_inhdr in_hdr; @@ -99,7 +95,6 @@ static void blk_done(struct virtqueue *vq) } __blk_end_request_all(vbr->req, error); - list_del(&vbr->list); mempool_free(vbr, vblk->pool); } /* In case queue is stopped waiting for more buffers. */ @@ -184,7 +179,6 @@ static bool do_req(struct request_queue *q, struct virtio_blk *vblk, return false; } - list_add_tail(&vbr->list,...

.../* Process context for config space updates */ @@ -55,7 +52,6 @@ struct virtio_blk struct virtblk_req { - struct list_head list; struct request *req; struct virtio_blk_outhdr out_hdr; struct virtio_scsi_inhdr in_hdr; @@ -99,7 +95,6 @@ static void blk_done(struct virtqueue *vq) } __blk_end_request_all(vbr->req, error); - list_del(&vbr->list); mempool_free(vbr, vblk->pool); } /* In case queue is stopped waiting for more buffers. */ @@ -184,7 +179,6 @@ static bool do_req(struct request_queue *q, struct virtio_blk *vblk, return false; } - list_add_tail(&vbr->list,...

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 All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

...used to track minor number allocations. */ int index; + /* Number of pending requests dispatched to driver. */ + int req_in_flight; + /* Scatterlist: can be too big for stack. */ struct scatterlist sg[/*sg_elems*/]; }; @@ -95,6 +98,7 @@ static void blk_done(struct virtqueue *vq) } __blk_end_request_all(vbr->req, error); + vblk->req_in_flight--; mempool_free(vbr, vblk->pool); } /* In case queue is stopped waiting for more buffers. */ @@ -190,6 +194,7 @@ static void do_virtblk_request(struct request_queue *q) while ((req = blk_peek_request(q)) != NULL) { BUG_ON(req->nr_ph...

...used to track minor number allocations. */ int index; + /* Number of pending requests dispatched to driver. */ + int req_in_flight; + /* Scatterlist: can be too big for stack. */ struct scatterlist sg[/*sg_elems*/]; }; @@ -95,6 +98,7 @@ static void blk_done(struct virtqueue *vq) } __blk_end_request_all(vbr->req, error); + vblk->req_in_flight--; mempool_free(vbr, vblk->pool); } /* In case queue is stopped waiting for more buffers. */ @@ -190,6 +194,7 @@ static void do_virtblk_request(struct request_queue *q) while ((req = blk_peek_request(q)) != NULL) { BUG_ON(req->nr_ph...

...valid context. The >>>> backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. >>> >>> Hi Jens, pls see below - it looks like the call to blk_mq_end_io >>> from IRQ context is causing the issue. >>> IIUC you switched virtio to this from __blk_end_request_all in >>> >>> commit 1cf7e9c68fe84248174e998922b39e508375e7c1 >>> virtio_blk: blk-mq support >>> >>> Is this always safe? >>> I note that at least one other driver is doing this: >>> drivers/block/mtip32xx/mtip32xx.c >> >>...

...valid context. The >>>> backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. >>> >>> Hi Jens, pls see below - it looks like the call to blk_mq_end_io >>> from IRQ context is causing the issue. >>> IIUC you switched virtio to this from __blk_end_request_all in >>> >>> commit 1cf7e9c68fe84248174e998922b39e508375e7c1 >>> virtio_blk: blk-mq support >>> >>> Is this always safe? >>> I note that at least one other driver is doing this: >>> drivers/block/mtip32xx/mtip32xx.c >> >>...

...e(vblk->disk->queue); /* Stop all the virtqueues. */ vdev->config->reset(vdev); flush_work(&vblk->config_work); - /* Abort requests dispatched to driver. */ - spin_lock_irqsave(&vblk->lock, flags); - while ((vbr = virtqueue_detach_unused_buf(vblk->vq))) { - __blk_end_request_all(vbr->req, -EIO); - mempool_free(vbr, vblk->pool); - } - spin_unlock_irqrestore(&vblk->lock, flags); - - blk_cleanup_queue(vblk->disk->queue); put_disk(vblk->disk); mempool_destroy(vblk->pool); vdev->config->del_vqs(vdev);

...e(vblk->disk->queue); /* Stop all the virtqueues. */ vdev->config->reset(vdev); flush_work(&vblk->config_work); - /* Abort requests dispatched to driver. */ - spin_lock_irqsave(&vblk->lock, flags); - while ((vbr = virtqueue_detach_unused_buf(vblk->vq))) { - __blk_end_request_all(vbr->req, -EIO); - mempool_free(vbr, vblk->pool); - } - spin_unlock_irqrestore(&vblk->lock, flags); - - blk_cleanup_queue(vblk->disk->queue); put_disk(vblk->disk); mempool_destroy(vblk->pool); vdev->config->del_vqs(vdev);

I am proposing these two patches for 3.2. They allow the backend to process the REQ_FUA request as well. Previous to these patches it only did REQ_FLUSH. There is also a bug-fix for the logic of how barrier/flushes were handled. The patches are based on a branch which also has ''feature-discard'' patches, so they won''t apply nativly on top of 3.1-rc5. Please review and