Received: by 10.223.176.46 with SMTP id f43csp3411926wra; Mon, 22 Jan 2018 13:51:49 -0800 (PST) X-Google-Smtp-Source: AH8x225O3/C2i2Wjwo/S2UoabgE5yLxw3k4t3y36+Pts/l6Ad4vX0guLPRkx8HDREgJy6mQf3EVj X-Received: by 10.36.142.70 with SMTP id h67mr516101ite.6.1516657909426; Mon, 22 Jan 2018 13:51:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516657909; cv=none; d=google.com; s=arc-20160816; b=u+o5zoJVg52rt6+r3WBUjpwbdY9VbdrCT7WMPy7XE5WReHOmrcb2xoh4ur47ePnNf5 0fBNKv2hF/lmdzKEbX2qguTMJuHIHtT9oYsSUObpou6CxhJL2PCvrQugeY4DBNCnQeCt zfbqV2wO59O8JxfRKwoSzPtQa7IM9woGkfvoy7tprmV5OPdM17yd6VlNinq6E9VO1gcX OtsmjHmSQJue7GgZPNiccOr+sh7ZbOTLgEtUJSprK20Awb0r/Qg/38UaHNRqAlPW7BG4 a1IxK846WZJMBmdxZmxoGdk9jVMRbI+PkF8L+hLugjTgyNi39OhiCN4KSIzo2SyaNvPF OMXw== 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=kbEso6b+xQwUTaj/iNEYd3QQ9BKOI+OPKPjWbc9pfoM=; b=gCukUFE2vxSnPjRM/6O+pNV/EkT0n51S4jeZ1Po+abIuFsWyzz81VlNm9iC5GCSpkh pphxeOPMZCQT1rLXJslGupA2klIhrz8tvFuA2RqpeRAvGVZFa3pGRfWI1vpgMEbI6CA9 8i2EqomZsh5H6hYjNj3UOfLa9xPO0hYxvM+hNHN+OnYT5QqvXP5KNK8kUndqj7Xc8Pq/ hLpicDRW3ciG9rGc1oGNB+6ygSpafOWGvD4hC13Cv8KfaKN1OU8iommtgmdyIOcxP6d4 Y7y6rXNTm80JdQ8f+C4MpIwnmMy9XAHshk9BdtQsUAVG2qTC4MqdzA7+Wnt8P5yMGoRL QG7w== 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 y135si6888483itb.85.2018.01.22.13.51.36; Mon, 22 Jan 2018 13:51:49 -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 S1751156AbeAVVvL (ORCPT + 99 others); Mon, 22 Jan 2018 16:51:11 -0500 Received: from mga14.intel.com ([192.55.52.115]:44900 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750942AbeAVVvK (ORCPT ); Mon, 22 Jan 2018 16:51:10 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 13:51:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,398,1511856000"; d="scan'208";a="21721089" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by FMSMGA003.fm.intel.com with ESMTP; 22 Jan 2018 13:51:09 -0800 Date: Mon, 22 Jan 2018 14:54:36 -0700 From: Keith Busch To: Christoph Hellwig Cc: Jianchao Wang , axboe@fb.com, sagi@grimberg.me, maxg@mellanox.com, james.smart@broadcom.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nvme-pci: ensure nvme_timeout complete before initializing procedure Message-ID: <20180122215436.GS12043@localhost.localdomain> References: <1516607585-1525-1-git-send-email-jianchao.w.wang@oracle.com> <20180122201423.GA30427@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180122201423.GA30427@lst.de> 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 Mon, Jan 22, 2018 at 09:14:23PM +0100, Christoph Hellwig wrote: > > Link: https://lkml.org/lkml/2018/1/19/68 > > Suggested-by: Keith Busch > > Signed-off-by: Keith Busch > > Signed-off-by: Jianchao Wang > > Why does this have a signoff from Keith? Right, I hadn't signed off that. I just trying to get feeback if someting like that was closing the theoretical gap, which it does. I actually have something similar in my patch queue I was about to send around this area, though. I don't like having the IO path take on the error handling, and I think ending unstarted requests directly will be better long term.