nvme: validate controller state before rescheduling keep alive
authorJames Smart <jsmart2021@gmail.com>
Wed, 28 Nov 2018 01:04:44 +0000 (17:04 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 21 Dec 2018 13:15:25 +0000 (14:15 +0100)
commitb2d58756858822778044de2a6a6f2e26bdc90873
treee45c0e6ff05c594c4f2475dee2d87782666a0ac7
parentcab9d27671db270b9fb8f4ed5d3a52cbc94c6438
nvme: validate controller state before rescheduling keep alive

[ Upstream commit 86880d646122240596d6719b642fee3213239994 ]

Delete operations are seeing NULL pointer references in call_timer_fn.
Tracking these back, the timer appears to be the keep alive timer.

nvme_keep_alive_work() which is tied to the timer that is cancelled
by nvme_stop_keep_alive(), simply starts the keep alive io but doesn't
wait for it's completion. So nvme_stop_keep_alive() only stops a timer
when it's pending. When a keep alive is in flight, there is no timer
running and the nvme_stop_keep_alive() will have no affect on the keep
alive io. Thus, if the io completes successfully, the keep alive timer
will be rescheduled.   In the failure case, delete is called, the
controller state is changed, the nvme_stop_keep_alive() is called while
the io is outstanding, and the delete path continues on. The keep
alive happens to successfully complete before the delete paths mark it
as aborted as part of the queue termination, so the timer is restarted.
The delete paths then tear down the controller, and later on the timer
code fires and the timer entry is now corrupt.

Fix by validating the controller state before rescheduling the keep
alive. Testing with the fix has confirmed the condition above was hit.

Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/nvme/host/core.c