From mboxrd@z Thu Jan 1 00:00:00 1970 From: axboe@fb.com (Jens Axboe) Date: Mon, 22 Dec 2014 13:08:35 -0700 Subject: [PATCH 0/4] nvme-blkmq fixes In-Reply-To: <549860A9.7060106@fb.com> References: <1419036856-16275-1-git-send-email-keith.busch@intel.com> <5495B2BF.8070602@fb.com> <5495CDFE.3060404@fb.com> <54984B10.6060907@fb.com> <549860A9.7060106@fb.com> Message-ID: <54987A43.9000807@fb.com> 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: >>>> [] ? pcpu_free_area+0x79/0xf8 >>>> [] ? __wake_up+0x35/0x46 >>>> [] ? blk_set_queue_dying+0x33/0x69 >>>> [] ? blk_cleanup_queue+0x25/0xfd >>>> [] ? __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: