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 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 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.

Quoted 3 lines

Also I found out I set nvmeq->cq_vector in the wrong place, messing up h/w completion queue interrupt setup (I was wondering why things got so slow!), so I'll fix that along with the struct alignment.

Oops... I'll just fold the patches, these are queued up for this round, so not a stable development base anyawy.

Signature · 1 line
Jens Axboe

Read the cover letter in its thread