NVMe: Fix blk-mq hot cpu notification
authorKeith Busch <keith.busch@intel.com>
Tue, 31 Mar 2015 16:37:17 +0000 (10:37 -0600)
committerJens Axboe <axboe@fb.com>
Tue, 31 Mar 2015 16:39:56 +0000 (10:39 -0600)
commit1efccc9ddb98fd533169669160201b027562af7e
tree6d7680fe16e50bb0fdd72e41d312accd80634fc7
parentfda631ffe5422424579e1649e04cc468d0215b85
NVMe: Fix blk-mq hot cpu notification

The driver may issue commands to a device that may never return, so its
request_queue could always have active requests while the controller is
running. Waiting for the queue to freeze could block forever, which is
what blk-mq's hot cpu notification handler was doing when nvme drives
were in use.

This has the nvme driver make the asynchronous event command's tag
reserved and does not keep the request active. We can't have more than
one since the request is released back to the request_queue before the
command is completed. Having only one avoids potential tag collisions,
and reserving the tag for this purpose prevents other admin tasks from
reusing the tag.

I also couldn't think of a scenario where issuing AEN requests single
depth is worse than issuing them in batches, so I don't think we lose
anything with this change.

As an added bonus, doing it this way removes "Cancelling I/O" warnings
observed when unbinding the nvme driver from a device.

Reported-by: Yigal Korman <yigal@plexistor.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
drivers/block/nvme-core.c