From patchwork Wed Apr 4 06:51:38 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Damien Le Moal X-Patchwork-Id: 10322131 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CF97660390 for ; Wed, 4 Apr 2018 06:52:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C09D728DBC for ; Wed, 4 Apr 2018 06:52:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B596F28DC1; Wed, 4 Apr 2018 06:52:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2946728DBC for ; Wed, 4 Apr 2018 06:52:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751097AbeDDGwD (ORCPT ); Wed, 4 Apr 2018 02:52:03 -0400 Received: from esa5.hgst.iphmx.com ([216.71.153.144]:15100 "EHLO esa5.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750736AbeDDGwC (ORCPT ); Wed, 4 Apr 2018 02:52:02 -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=1522824723; x=1554360723; h=from:to:cc:subject:date:message-id; bh=WclQt3kJnyXqmpUJmDDsLXWnLovYvWaSDaEZebicPMY=; b=in23q8A5Jhib8CPvzvegrhYiwwknWvY9J4cYaKkPDhnQl5wnDwGmqIrF 0t+oj8JjLG9KldqI11j5jJDLXZH/xGMG4cUxNIqxkwbLBkGbWWyYOWrz4 ZpfnIztdJrF8gDyHqWm+7YCMXKwZMlKkp3uYcuSvFg752A+/sZIwLM5Hf ZcNxa2A49hIK0VNNUbtD6XFkVZlSMCJBVV4gzuS+wkX1eczpYur7zNUdP yO2eIEIULyCPwzuSfpGu5DNQTZuDlwNHk2ZPm76ADmFTi8IOFMLuj1ITB qGHnXQP8rsqiKFZzRWI3HO1JnOVCHlzUXT+ozQ1Kjq2b5NVzgrEG3ywIj g==; X-IronPort-AV: E=Sophos;i="5.48,405,1517846400"; d="scan'208";a="75216385" Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 04 Apr 2018 14:51:53 +0800 Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP; 03 Apr 2018 23:44:48 -0700 Received: from washi.fujisawa.hgst.com ([10.149.53.254]) by uls-op-cesaip02.wdc.com with ESMTP; 03 Apr 2018 23:51:52 -0700 From: Damien Le Moal To: linux-scsi@vger.kernel.org, "Martin K . Petersen" Cc: Bart Van Assche , Hannes Reinecke , Hannes Reinecke , stable@vger.kernel.org Subject: [PATCH] scsi: Fix failed request error code Date: Wed, 4 Apr 2018 15:51:38 +0900 Message-Id: <20180404065138.25534-1-damien.lemoal@wdc.com> X-Mailer: git-send-email 2.14.3 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP With the introduction of commit e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking additional sense information will have a return code set to BLK_STS_OK. This results in the request issuer to see successful request execution despite the failure. An example of such case is an unaligned write on a host managed ZAC disk connected to a SAS HBA with a malfunctioning SAT. The unaligned write command gets aborted but has no additional sense information. sd 10:0:0:0: [sde] tag#3905 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 10:0:0:0: [sde] tag#3905 Sense Key : Aborted Command [current] sd 10:0:0:0: [sde] tag#3905 Add. Sense: No additional sense information sd 10:0:0:0: [sde] tag#3905 CDB: Write(16) 8a 00 00 00 00 00 02 0c 00 01 00 00 00 01 00 00 print_req_error: I/O error, dev sde, sector 274726920 In scsi_io_completion(), sense key handling to not change the request error code and success being reported to the issuer. Fix this by making sure that the error code always indicates an error if scsi_io_completion() decide that the action to be taken for a failed command is to not retry it and terminate it immediately (ACTION_FAIL) . Signed-off-by: Damien Le Moal Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()") Cc: Hannes Reinecke Cc: --- drivers/scsi/scsi_lib.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index c84f931388f2..87579bfcc186 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1002,6 +1002,15 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes) scsi_print_command(cmd); } } + /* + * The command failed and should not be retried. If the host + * byte is DID_OK, then __scsi_error_from_host_byte() returned + * BLK_STS_OK and error indicates a success. Make sure to not + * use that as the completion code and always return an + * I/O error. + */ + if (error == BLK_STS_OK) + error = BLK_STS_IOERR; if (!scsi_end_request(req, error, blk_rq_err_bytes(req), 0)) return; /*FALLTHRU*/