From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751085AbdE3HTD (ORCPT <rfc822;w@1wt.eu>);
        Tue, 30 May 2017 03:19:03 -0400
Received: from mx2.mpynet.fi ([82.197.21.85]:53225 "EHLO mx2.mpynet.fi"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750890AbdE3HTC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 30 May 2017 03:19:02 -0400
Date: Tue, 30 May 2017 10:18:50 +0300
From: Rakesh Pandit <rakesh@tuxera.com>
To: Christoph Hellwig <hch@lst.de>
CC: <linux-nvme@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        "Jens Axboe" <axboe@fb.com>, Sagi Grimberg <sagi@grimberg.me>,
        Andy Lutomirski <luto@kernel.org>, Keith Busch <keith.busch@intel.com>
Subject: Re: [PATCH 1/1] nvme: fix nvme_remove going to uninterruptible sleep
 for ever
Message-ID: <20170530071850.GA2713@hercules.tuxera.com>
References: <20170529062952.GA6717@hercules.tuxera.com>
 <20170529175839.GC25061@lst.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170529175839.GC25061@lst.de>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, May 29, 2017 at 07:58:39PM +0200, Christoph Hellwig wrote:
> On Mon, May 29, 2017 at 09:29:54AM +0300, Rakesh Pandit wrote:
> > 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:
...
> 
> What do you think about moving this into the beginning of
> nvme_configure_apst instead?  And please add a comment while you're
> at it.

Thanks, makes sense.  I have posted V2.