Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp93088imm; Thu, 21 Jun 2018 14:33:00 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJkpOVVqZHDPTM3Pne2UOomLl+ScQC9iHLyeKFz5+eruaJwxX2U4ZUgW9Duy2cqMPLYurMB X-Received: by 2002:a17:902:3c5:: with SMTP id d63-v6mr30845644pld.163.1529616780932; Thu, 21 Jun 2018 14:33:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529616780; cv=none; d=google.com; s=arc-20160816; b=Oa/PtXzqUsNjqocVYl+dkdUoQ+NTbA197cUsXKl5jLrgTZnkBu89cmPjmID9svkEKG T21JRIWO9W6Ph1AGK/mFmlTfUcWn5SzK3zb8Qw/E2dVnZOwHxia1o1eDW/EJCVzDresZ 1Xe+aAmJvX4mPpmGi+u8pT5U1+yeigziGsU0wiUMa5w4G27MBJo+g4JvU60EjcO060RK mw9+XXDKmBRf8r8TXL4LpADClA3bexXEeHFfQBsaOZcuLqwd0SBEk+/qHi+99SI4Jj2t jVB3X46pfIFM3FWA5GGGgccbu3nlQ5oKRTai8VKKAcSz3xkezGccUxkEKYoB5ThTnoKh 4udQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=uMQrwRGeZHdteqcGgntfN5huBRGkzASKOGAuf1uM2M4=; b=ThExUSa0ClAygYnbevXgeDDOhOt5hqKFcn+tQRbKryp/4of/+tHTyFGjnsdy2BOR9H x3/SecYnlhIg7rQbhnToOTv/9UMEJjyoqTC8KxDOyjohNUi0eke7buIDo+GdQ9Xw0xv+ 64B4xLTyANdKwePM0gn17ACZuC8p2eMO1z2QR2z971S76eRftVD10JxPyXAX1nrpmrBi 6ysOauCZLLL7HzFUOWAOjjBRLTZcAWDR7ujb8r+CeZnKK40SzTRi94mXeEVzqLX35URc u9mpwxhslcTInjSKwhrcz3uJH1YhJJP/dkQTDq7P5tCskNNJNQw+RfnD9w2tnMKYy+ah 8/lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@wdc.com header.s=dkim.wdc.com header.b=FGB5WFAW; 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 a80-v6si5943255pfg.200.2018.06.21.14.32.46; Thu, 21 Jun 2018 14:33:00 -0700 (PDT) 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; dkim=fail header.i=@wdc.com header.s=dkim.wdc.com header.b=FGB5WFAW; 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 S934103AbeFUVap (ORCPT + 99 others); Thu, 21 Jun 2018 17:30:45 -0400 Received: from esa3.hgst.iphmx.com ([216.71.153.141]:8140 "EHLO esa3.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933835AbeFUVam (ORCPT ); Thu, 21 Jun 2018 17:30:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1529616643; x=1561152643; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Nb1XFb6TkFOeT0je+OzTptD4wrvNNkf78Hovi2nidbc=; b=FGB5WFAWdz1IWZ0FzeRz5bPvD9uXimZZVW8kxTEig2SiFTaKjgAHjnAu lpYyXl/DEhjAq8wesiei7QChoyPXDODsxoFCqucVsdLyP59N8Mj4CMj7y S+MzhF3UTbj+WdlAgOzbMd+FU2Fe4hKeViNkxLh3gSlzuAGlaHupxrRAR ysd0rQIqQgVgoASxJASwF6tIZO+Wvd54lAJD4j+u1ytCu+ca1Ju1LnNHd X7YKa2VzgAzJ8gS4U41OkprNguR925jYdwjK+HaRQXAfyj/aMYaHLTNVv qFjTGuXj5zUasfY/Ferq2mVLS6kO9xComJyEFi0UtCggMReKIaZqynFYm g==; X-IronPort-AV: E=Sophos;i="5.51,253,1526313600"; d="scan'208";a="83607287" Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 22 Jun 2018 05:30:42 +0800 Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP; 21 Jun 2018 14:20:29 -0700 Received: from thinkpad-bart.sdcorp.global.sandisk.com (HELO [10.111.67.248]) ([10.111.67.248]) by uls-op-cesaip01.wdc.com with ESMTP; 21 Jun 2018 14:30:40 -0700 Subject: Re: [PATCH 0/5]stop normal completion path entering a timeout req To: Keith Busch 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" References: <1529500964-28429-1-git-send-email-jianchao.w.wang@oracle.com> <20180620181601.GA24145@localhost.localdomain> <20180621081900.GA5183@lst.de> <84a5b54c318b130f47775747d37dc139c27ebda7.camel@wdc.com> <20180621211529.GA27589@localhost.localdomain> From: Bart Van Assche Message-ID: Date: Thu, 21 Jun 2018 14:30:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180621211529.GA27589@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/21/18 14:12, Keith Busch wrote: > 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. Why were the patch "blk-mq: Remove generation seqeunce" and related patches rushed upstream without having given anyone a chance to review these patches? The approach of these patches is inferior to at least one alternative that was available. The code that is currently upstream spreads the request state over multiple (three) variables while an alternative approach was presented that stores the request state in a single variable. I think the number of fix-up patches that is needed for the approach that is currently upstream shows that the upstream approach is inferior. I'm referring to "[PATCH v14] blk-mq: Rework blk-mq timeout handling again" (https://marc.info/?l=linux-block&m=152703042412228). Bart.