From patchwork Fri May 13 08:07:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jinpu Wang X-Patchwork-Id: 9089341 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5C4FF9F441 for ; Fri, 13 May 2016 08:08:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8F00B201BC for ; Fri, 13 May 2016 08:08:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5CB722021A for ; Fri, 13 May 2016 08:08:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752532AbcEMIIX (ORCPT ); Fri, 13 May 2016 04:08:23 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:35267 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751322AbcEMIIR (ORCPT ); Fri, 13 May 2016 04:08:17 -0400 Received: by mail-oi0-f47.google.com with SMTP id x19so159026017oix.2 for ; Fri, 13 May 2016 01:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=profitbricks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Zm4VM4tPGKT0pSxZ4uz2oheMDMyr/pH935nj364I7NI=; b=zEcYVIVhjWPJmjx3y9MQQw+pMtibmdwP81rNzI7YkAenyuAf77IbkStI8CecdXyQYt /NCD41OFrbVp4/6Jh6fsHW2gJpzNSirrL4ZZPQx+++u0EU0EJOOJ9iSoHAppGAcE5Akl fJ+/ddaQBJkDW1sHvCEVvuuYx/J5M5kUvHrYT51qqSZ9FhvRknUzWFMZOddJS6VVzMWf H75fPQecu4OfPG6WSoM/FEMDV366vr5Skeb1FRr+DGJHENPlmzHct/1LXJex6d3mZ/1o 6qSK5QSqVMY1cXFDOAPWxvhiKPsNj/gqEKf+xcmu8pRKAKuTrVWQkmpZNfOkPNMDFaNP EcMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Zm4VM4tPGKT0pSxZ4uz2oheMDMyr/pH935nj364I7NI=; b=GqRqi8c+i0W0mUI9j8nDWF9G/EKYcOcwc7guu3Z9Rl0Cu5ZL0zpZbxI5d6equ16ic+ cxBk4UjBIfdebyTMhNXlQwf3+1N+StXFMbbU1u7bT5gLoF6CIn0duoZELWNzGUbSXhNx skFKsIuKoBbyV7FkaLySkJ6zUOEaw1VbEMGm3QsBI/R1TwZM5wkYh6autTBDcccTos0b yckAfoaQ7zfz6QjVWI50/UiJVj8JbCz7QGa1WlhRn/XYUHgRTOOxM2afGRgVXj/wHoMb wat2uGjBozgKl6gnzpLf+WgAS+InzXe05Cf+oHtXX3EfFspCjf9bgl0EaNr33HeZYtMM bFBg== X-Gm-Message-State: AOPr4FXDuNOtTcc+pK8yoYufSfyF7WH6/ecGC/6FuMg9hl5aNnGdTUkVkbhGoAv3aSgEUtvccRI/vXwQi/yxK1oE X-Received: by 10.157.46.70 with SMTP id c6mr8345066otd.106.1463126895628; Fri, 13 May 2016 01:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.5 with HTTP; Fri, 13 May 2016 01:07:56 -0700 (PDT) From: Jinpu Wang Date: Fri, 13 May 2016 10:07:56 +0200 Message-ID: Subject: [PATCHv3]scsi: don't fail zero length request too early To: "James E.J. Bottomley" , Hannes Reinecke , Bart Van Assche , Christoph Hellwig , "Martin K. Petersen" , Sebastian Parschauer , linux-scsi@vger.kernel.org Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham 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 Hi James, and all, I guess you're busy on other staff, so I create patch below as you suggested, I think we also need this into stable. From 99eab170653544fa1e1bc9511ec055ba70e183d2 Mon Sep 17 00:00:00 2001 From: Jack Wang Date: Fri, 13 May 2016 09:53:21 +0200 Subject: [PATCH] scsi: don't fail zero length request too early We hit IO error in our production when SYNC on multipath devices during resize device on target side, the problem turns out scsi driver passes up as IO error when sense data is UNIT_ATTENTION and ASC && ASCQ indicate Capacity data has changed, even storage side sync the data properly. Dig it further turns out we need special case on zero length commands (currently only FLUSH), when it fails, we always need to drop down into retry code. Reported-by: Sebastian Parschauer Suggested-by: James Bottomley Signed-off-by: Jack Wang --- drivers/scsi/scsi_lib.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) /* From 99eab170653544fa1e1bc9511ec055ba70e183d2 Mon Sep 17 00:00:00 2001 From: Jack Wang Date: Fri, 13 May 2016 09:53:21 +0200 Subject: [PATCH] scsi: don't fail zero length request too early We hit IO error in our production when SYNC on multipath devices during resize device on target side, the problem turns out scsi driver passes up as IO error when sense data is UNIT_ATTENTION and ASC && ASCQ indicate Capacity data has changed, even storage side sync the data properly. Dig it further turns out we need special case on zero length commands (currently only FLUSH), when it fails, we always need to drop down into retry code. Reported-by: Sebastian Parschauer Suggested-by: James Bottomley Signed-off-by: Jack Wang --- drivers/scsi/scsi_lib.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 8106515..5a97866 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -911,9 +911,12 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes) } /* - * If we finished all bytes in the request we are done now. + * special case: failed zero length commands always need to + * drop down into the retry code. Otherwise, if we finished + * all bytes in the request we are done now. */ - if (!scsi_end_request(req, error, good_bytes, 0)) + if (!(good_bytes == 0 && blk_rq_bytes(req) == 0 && result != 0) && + !scsi_end_request(req, error, good_bytes, 0)) return; /* -- 1.9.1