Skip to content

nvme-blkmq fixes

Jens Axboe linux-nvme 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 4 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 4 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/4] nvme-blkmq fixes
Quoted 14 lines · Jens Axboe
Quoted 13 lines · Keith Busch
Quoted 11 lines · Jens Axboe
Quoted 6 lines · Keith Busch
Call Trace:
  [<ffffffff810e75ae>] ? pcpu_free_area+0x79/0xf8
  [<ffffffff8106579f>] ? __wake_up+0x35/0x46
  [<ffffffff811bb67d>] ? blk_set_queue_dying+0x33/0x69
  [<ffffffff811bce39>] ? blk_cleanup_queue+0x25/0xfd
  [<ffffffff812b2ca5>] ? __dm_destroy+0x22c/0x254

I wonder if it cleaned up the requests lists upfront, otherwise I don't see where that would crash. I'll look into that. This particular patch isn't pushed out yet.

Quoted 8 lines
Quoted 6 lines

The above failure happens because dm called blk_alloc_queue(), but never made it far enough to call blk_init_allocated_queue(). One way to fix is call blk_init_rl() from blk_alloc_queue_node() instead of blk_init_allocated_queue(). I'm not sure if that's the right way to fix it or if blk_cleanup_queue() should somehow be aware if the request_list was initialized in the first place.

OK, I'll take care of this one.

Should be enough to just check for ->rq_pool being initialized or not - if it is, we could have waiters and we know the waitqueues have been setup, etc.

V2 attached.

Signature · 9 lines
Jens Axboe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: blk-mq-wake-on-dying-v2.patch
Type: text/x-patch
Size: 3856 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20141222/1d3ba333/attachment.bin>

Read the cover letter in its thread