From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9D8AC43142 for ; Thu, 21 Jun 2018 21:12:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5A62A223AD for ; Thu, 21 Jun 2018 21:12:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A62A223AD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933604AbeFUVMS (ORCPT ); Thu, 21 Jun 2018 17:12:18 -0400 Received: from mga03.intel.com ([134.134.136.65]:27587 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933346AbeFUVMQ (ORCPT ); Thu, 21 Jun 2018 17:12:16 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 14:12:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,253,1526367600"; d="scan'208";a="66179450" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga001.fm.intel.com with ESMTP; 21 Jun 2018 14:12:15 -0700 Date: Thu, 21 Jun 2018 15:15:29 -0600 From: Keith Busch To: Bart Van Assche Cc: "hch@lst.de" , "jianchao.w.wang@oracle.com" , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "martin.petersen@oracle.com" , "axboe@kernel.dk" , "linux-scsi@vger.kernel.org" , "josef@toxicpanda.com" , "ulf.hansson@linaro.org" Subject: Re: [PATCH 0/5]stop normal completion path entering a timeout req Message-ID: <20180621211529.GA27589@localhost.localdomain> References: <1529500964-28429-1-git-send-email-jianchao.w.wang@oracle.com> <20180620181601.GA24145@localhost.localdomain> <20180621081900.GA5183@lst.de> <84a5b54c318b130f47775747d37dc139c27ebda7.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84a5b54c318b130f47775747d37dc139c27ebda7.camel@wdc.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, Jun 21, 2018 at 06:21:09PM +0000, Bart Van Assche wrote: > That's not how the SCSI core works. How does it work? Jianchao is advocating for holes in software to ignore reacting to hardware events and force unnecessary error escalation. Putting holes in kernel software can't possibly be our only recourse.