[PATCH 0/4] nvme-blkmq fixes

[axboe@fb.com (Jens Axboe)]

On 12/22/2014 11:19 AM, Jens Axboe wrote:
> On 12/22/2014 11:17 AM, Keith Busch wrote:
>> On Mon, 22 Dec 2014, Jens Axboe wrote:
>>> On 12/22/2014 09:38 AM, Keith Busch wrote:
>>>> 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.
>>
>> 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.

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