From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750971AbdE2G35 (ORCPT ); Mon, 29 May 2017 02:29:57 -0400 Received: from mx1.mpynet.fi ([82.197.21.84]:49977 "EHLO mx1.mpynet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750825AbdE2G34 (ORCPT ); Mon, 29 May 2017 02:29:56 -0400 Date: Mon, 29 May 2017 09:29:54 +0300 From: Rakesh Pandit To: , CC: Jens Axboe , Christoph Hellwig , Sagi Grimberg , Andy Lutomirski , Keith Busch Subject: [PATCH 1/1] nvme: fix nvme_remove going to uninterruptible sleep for ever Message-ID: <20170529062952.GA6717@hercules.tuxera.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-ClientProxiedBy: tuxera-exch.ad.tuxera.com (10.20.48.11) To tuxera-exch.ad.tuxera.com (10.20.48.11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Once controller is in DEAD or DELETING state a call to delete_destroy from nvme_uninit_ctrl results in setting the latency tolerance via nvme_set_latency_tolerance callback even though queues have already been killed. This in turn leads the PID to go into uninterruptible sleep and prevents removal of nvme controller from completion. The stack trace is: [] blk_execute_rq+0x56/0x80 [] __nvme_submit_sync_cmd+0x89/0xf0 [] nvme_set_features+0x5e/0x90 [] nvme_configure_apst+0x166/0x200 [] nvme_set_latency_tolerance+0x35/0x50 [] apply_constraint+0xb1/0xc0 [] dev_pm_qos_constraints_destroy+0xf4/0x1f0 [] dpm_sysfs_remove+0x2a/0x60 [] device_del+0x101/0x320 [] device_unregister+0x1a/0x60 [] device_destroy+0x3c/0x50 [] nvme_uninit_ctrl+0x45/0xa0 [] nvme_remove+0x78/0x110 [] pci_device_remove+0x39/0xb0 [] device_release_driver_internal+0x155/0x210 [] device_release_driver+0x12/0x20 [] nvme_remove_dead_ctrl_work+0x6b/0x70 [] process_one_work+0x18c/0x3a0 [] worker_thread+0x4e/0x3b0 [] kthread+0x109/0x140 [] ret_from_fork+0x2c/0x40 [] 0xffffffffffffffff and PID is in 'D' state. Attached patch returns from callback when controller is either DELETING state or DEAD which can only happen once we are in nvme_remove and allows removal to complete and release remaining resources after nvme_uninit_ctrl. Fixes: c5552fde102fc ("nvme: Enable autonomous power state transitions") Signed-off-by: Rakesh Pandit --- drivers/nvme/host/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index a609264..c1a632c 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1456,6 +1456,9 @@ static void nvme_set_latency_tolerance(struct device *dev, s32 val) struct nvme_ctrl *ctrl = dev_get_drvdata(dev); u64 latency; + if (ctrl->state == NVME_CTRL_DELETING || ctrl->state == NVME_CTRL_DEAD) + return; + switch (val) { case PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT: case PM_QOS_LATENCY_ANY: -- 2.9.3