From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751878AbdE3OYi (ORCPT ); Tue, 30 May 2017 10:24:38 -0400 Received: from mx1.mpynet.fi ([82.197.21.84]:53298 "EHLO mx1.mpynet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbdE3OXt (ORCPT ); Tue, 30 May 2017 10:23:49 -0400 Date: Tue, 30 May 2017 17:23:46 +0300 From: Rakesh Pandit To: Sagi Grimberg CC: , , "Jens Axboe" , Keith Busch , Christoph Hellwig , Andy Lutomirski Subject: Re: [PATCH V2] nvme: fix nvme_remove going to uninterruptible sleep for ever Message-ID: <20170530142346.GA39428@dhcp-216.srv.tuxera.com> References: <20170530071610.GA2679@hercules.tuxera.com> <4da7c939-1f54-80e5-48fc-06e58e14f018@grimberg.me> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4da7c939-1f54-80e5-48fc-06e58e14f018@grimberg.me> User-Agent: Mutt/1.7.1 (2016-10-04) 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 On Tue, May 30, 2017 at 01:18:55PM +0300, Sagi Grimberg wrote: > > > /* > > + * Avoid configuration and syncing commands if controller is already > > + * being removed and queues have been killed. > > + */ > > + if (ctrl->state == NVME_CTRL_DELETING || ctrl->state == NVME_CTRL_DEAD) > > + return; > > + > > Hey Rakesh, Christoph, > > Given that the issue is for sync command submission during controller > removal, I'm wandering if we should perhaps move this check to > __nvme_submit_sync_cmd? > > AFAICT user-space can just as easily trigger set_features in the same > condition which will trigger the hang couldn't it? Seems possible. But it seems worth keeping this check as it avoids the instructions between start of nvme_configure_apst and __nvme_submit_sync_cmd. This check seems to solve more severe hang as PID which started off from nvme_remove eventually hangs itself on blk_execute_rq.. We can fix user-space triggered set_features higger up e.g. in nvme_ioctl by putting same check. Introduction of a separate state NVME_CTRL_SCHED_RESET (being discussed in another thread) has additional advantage of making sure that only one thread is going through resetting and eventually through removal (if required) and solves lot of problems. It makes sense to push this separately because of above reasons and we can fix user space trigger of deadlock once discussion on another thread has moved forward on introducing of new state.