Received: by 10.223.176.46 with SMTP id f43csp670760wra; Thu, 18 Jan 2018 23:59:43 -0800 (PST) X-Google-Smtp-Source: ACJfBosDXBhpuNnuciwIxX061CFJKLYVQHUT3p3KQAnGqqUEBEMX9GV4tiFy10VLO4Ko2jPi3yrn X-Received: by 2002:a17:902:244:: with SMTP id 62-v6mr1171511plc.409.1516348783563; Thu, 18 Jan 2018 23:59:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516348783; cv=none; d=google.com; s=arc-20160816; b=ZptJxmDZtNhEvO6GrTtaNEcgCpJk7npha8JRrK6hWidSqDrS3VtHyJb4cGmRK7QTT3 1eHZc0BDZtKhmoR8ksI97X8MMU1wHtl7WxYdtEV/xHNn2wpxwn/a6eAd9m6n2Dm5FwHW E6Ar8qWwSKC5hZGpC6bgpgm/LKcuktay2LjwkFGGVLUnus+Ue0wTIscYb3pbR6lwBv59 J2SAIhwVWVyhov3tpmHrQIMjtExvDaXRuUTjtT0nC3/pe5lprEizr3POur1lu9MI8fIc nvNMumbGVOPnRfObjJbu4T6rqPcnfzgOkOTTgl58n5Pwh7E8wz5yWMIMBydOfS3CxE+2 vwBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=mtn/Bk4wTtFYzLPAWli3XeRXEcI/GE/s82WpSp7y/88=; b=TbxumP8tmAgkWdqQ54NcH83oXfR4YLpFmOK7DV38pI9Wwl/sxOWDA0hoKvg03HKoT2 noQ0CrpcJ+Df4/cc53GgLwRufui5GLTblBub0S26wUp3QXbMoIPI76jb5wIAQDv1iEru gyUpaZS6hSGT48zDXqVYst6Vmuj0jWak3br+QIPTwn/BZEG1iyskk2TSZF/Eb+mkGduy rJGH72EYqSfSANOIPFAeqI8TUEbP0zouUQgIpfGk0X5tGjjM659pzwXer5bHfSCDEvrd fkxG95Cedu99OEKrGebbFpoOXQGvI9QtQgv8fhMT/r1XlPPOlQtaQFvlq8+gv8Hy6YyS O21g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t18si7518080pgv.668.2018.01.18.23.59.29; Thu, 18 Jan 2018 23:59:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754754AbeASH6U (ORCPT + 99 others); Fri, 19 Jan 2018 02:58:20 -0500 Received: from mga05.intel.com ([192.55.52.43]:21206 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750948AbeASH6N (ORCPT ); Fri, 19 Jan 2018 02:58:13 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 23:58:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,381,1511856000"; d="scan'208";a="10963715" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by orsmga007.jf.intel.com with ESMTP; 18 Jan 2018 23:58:10 -0800 Date: Fri, 19 Jan 2018 01:01:30 -0700 From: Keith Busch To: Jianchao Wang Cc: axboe@fb.com, hch@lst.de, sagi@grimberg.me, maxg@mellanox.com, james.smart@broadcom.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V5 0/2] nvme-pci: fix the timeout case when reset is ongoing Message-ID: <20180119080130.GE12043@localhost.localdomain> References: <1516270202-8051-1-git-send-email-jianchao.w.wang@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516270202-8051-1-git-send-email-jianchao.w.wang@oracle.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 18, 2018 at 06:10:00PM +0800, Jianchao Wang wrote: > Hello > > Please consider the following scenario. > nvme_reset_ctrl > -> set state to RESETTING > -> queue reset_work > (scheduling) > nvme_reset_work > -> nvme_dev_disable > -> quiesce queues > -> nvme_cancel_request > on outstanding requests > -------------------------------_boundary_ > -> nvme initializing (issue request on adminq) > > Before the _boundary_, not only quiesce the queues, but only cancel > all the outstanding requests. > > A request could expire when the ctrl state is RESETTING. > - If the timeout occur before the _boundary_, the expired requests > are from the previous work. > - Otherwise, the expired requests are from the controller initializing > procedure, such as sending cq/sq create commands to adminq to setup > io queues. > In current implementation, nvme_timeout cannot identify the _boundary_ > so only handles second case above. Bare with me a moment, as I'm only just now getting a real chance to look at this, and I'm not quite sure I follow what problem this is solving. The nvme_dev_disable routine makes forward progress without depending on timeout handling to complete expired commands. Once controller disabling completes, there can't possibly be any started requests that can expire. So we don't need nvme_timeout to do anything for requests above the boundary.