From patchwork Tue Feb 16 12:14:13 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiangyiwen X-Patchwork-Id: 8324611 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id AE1F1C02AE for ; Tue, 16 Feb 2016 12:14:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DDFE82024F for ; Tue, 16 Feb 2016 12:14:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DC3F22025B for ; Tue, 16 Feb 2016 12:14:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755081AbcBPMOd (ORCPT ); Tue, 16 Feb 2016 07:14:33 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:50957 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755174AbcBPMO3 (ORCPT ); Tue, 16 Feb 2016 07:14:29 -0500 Received: from 172.24.1.49 (EHLO SZXEML424-HUB.china.huawei.com) ([172.24.1.49]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEQ20913; Tue, 16 Feb 2016 20:14:19 +0800 (CST) Received: from [127.0.0.1] (10.177.16.168) by SZXEML424-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server id 14.3.235.1; Tue, 16 Feb 2016 20:14:15 +0800 Subject: Re: [PATCH] block/sd: Return -EREMOTEIO when WRITE SAME and DISCARD are disabled To: "Martin K. Petersen" References: <20160204042528.GA15599@redhat.com> <1454568483-11298-1-git-send-email-martin.petersen@oracle.com> <56B316EA.9090803@huawei.com> CC: , , , James Bottomley From: jiangyiwen Message-ID: <56C31295.2020309@huawei.com> Date: Tue, 16 Feb 2016 20:14:13 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.177.16.168] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56C3129D.024E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a7d1733ae4b24ce2fdd3214ffd8ad674 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 2016/2/5 11:13, Martin K. Petersen wrote: >>>>>> "Yiwen" == jiangyiwen writes: > > Yiwen, > > Yiwen> First, I don't understand why blk_peek_request() return > Yiwen> EREMOTEIO, as I know, in this situation we only prepare scsi > Yiwen> command without sending to device, and I think EREMOTEIO should > Yiwen> be returned only when IO has already sent to device, maybe I > Yiwen> don't understand definition of EREMOTEIO. So, Why don't return > Yiwen> the errno with EOPNOTSUPP? > > DM currently has special handling for EREMOTEIO failures (because that's > what we'd return when a device responds with ILLEGAL REQUEST). > > I am not opposed to returning EOPNOTSUPP but it would require more > changes and since this is a bugfix for stable I want to keep it as small > as possible. > > Yiwen> In addition, I still worried with whether there has other > Yiwen> situations which will return EIO or other error. In this way, > Yiwen> MD/DM still can happen this type of problem, so I think may be in > Yiwen> multipath we still needs a protection to avoid it. > > There are various error scenarios where we can end up bailing with a > BLKPREP_KILL. But the general rule of thumb is that these conditions all > demand a retry. The optional commands like WRITE SAME and UNMAP are > special in that they are irrecoverable. > > Yiwen> At last, I have a additional problem, I remember that you > Yiwen> previously send a series of patches about XCOPY, why don't have > Yiwen> any news latter later? I very much expect that I can see these > Yiwen> patches which are merged into kernel. > > I am working on a refresh of the series that includes token-based copy > offload support in addition to EXTENDED COPY. The patches depend on Mike > Christie's request flag patch series which has yet to be merged. > Hi Martin, I tested this code, but found a problem. When called scsi_prep_fn return BLKPREP_INVALID, we should use the same code with BLKPREP_KILL in scsi_prep_return. This patch should add a line of code as follows: --- drivers/scsi/scsi_lib.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index dd8ad2a..d8d2198 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1343,6 +1343,7 @@ scsi_prep_return(struct request_queue *q, struct request *req, int ret) switch (ret) { case BLKPREP_KILL: + case BLKPREP_INVALID: req->errors = DID_NO_CONNECT << 16; /* release the command and kill it */ if (req->special) {