From patchwork Sat Mar 4 00:50:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 9603719 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 0AF83602B4 for ; Sat, 4 Mar 2017 00:51:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E8CB4285C5 for ; Sat, 4 Mar 2017 00:51:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DD33528608; Sat, 4 Mar 2017 00:51:17 +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.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI 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 B7ECA285C5 for ; Sat, 4 Mar 2017 00:51:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751843AbdCDAvO (ORCPT ); Fri, 3 Mar 2017 19:51:14 -0500 Received: from mail-pg0-f51.google.com ([74.125.83.51]:33493 "EHLO mail-pg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751584AbdCDAvN (ORCPT ); Fri, 3 Mar 2017 19:51:13 -0500 Received: by mail-pg0-f51.google.com with SMTP id 25so49056898pgy.0 for ; Fri, 03 Mar 2017 16:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Q1ZIn+8uVuKqsdzRInd/dhrPI+ISDdknvjyK4yIbugg=; b=UMRDWAe9frSrIS+x/Fqoeri8AqIGvWOhUMVHU3d4xlZylYWcgrRfLzDw14D/D6vJHT ddHjfXbW1dnKf/KIBkM+4rmPtwwkeOr713MPbAhXqviWGzVL18GXPbaeQnMU/ItNTFYc oTtOnaKKPwYBXvwI+0XJfVQ84XjxxUyvH2m/XH8AJZ2AHilzxT8Z3b/hzw9W7MqKYF+0 Q6RgujWQDkTaQwndRMbpy/PD/K6VKh2dJsH1O2JtPbMCMGCEzWTI8k9ljP9PDN280X7D Djqllk9GFFwR82Q8FwMzqQHR3OcbeLcfwH8tHhdjexr9w8OPVMFDSvePiF5cHpZYgm3i Op5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Q1ZIn+8uVuKqsdzRInd/dhrPI+ISDdknvjyK4yIbugg=; b=RfGV0aqYjOcWGuZTUIoZw7BJx0FVzMuVDP1lIqZUYp7agXkFhNB3JvwrzDF9RsMSBY iVWKe/7zHpwpeZ5+mU8Zcaz/kMQgF13YapsgrPZhXcPrqjmBYLp0m+nW/HbGxjbx153g DSxE6/kzHPSvhNlPoXnEHiIvgv2mDyaImNNqdekxq/WDWiWCKCcWq/JIuWzkh3pw9Nk0 9MeqL+WQ64xupyz8ghqoZqKR+ZDu/5krMZ9LVB2LZUKI8wWMDUpfEs73B3nqarwmDBVs 7rt4PP3vnjTw6B7sXroVh9NJlzfT5yx7LRjmKWpYsNZdHK5aIIFQ5AV2g+NvJZ0IiKqq 2Z/w== X-Gm-Message-State: AMke39lq1z7AjuLgW1CgiSQStFetOgSwzr/kGk/R6xy02z/+ciggViDFvI5au8+WqZAH3A== X-Received: by 10.98.63.140 with SMTP id z12mr6871375pfj.129.1488588619003; Fri, 03 Mar 2017 16:50:19 -0800 (PST) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id y201sm13892638pfb.16.2017.03.03.16.50.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Mar 2017 16:50:18 -0800 (PST) Date: Fri, 3 Mar 2017 16:50:11 -0800 From: Stephen Hemminger To: James Bottomley Cc: Hannes Reinecke , Christoph Hellwig , James Bottomley , Jens Axboe , Linus Torvalds , "Martin K. Petersen" , "K. Y. Srinivasan" , Dexuan Cui , Long Li , Josh Poulson , v-adsuho@microsoft.com, linux-scsi@vger.kernel.org, Haiyang Zhang Subject: [RFC] hv_storvsc: error handling. Message-ID: <20170303165011.53a38794@xeon-e3> In-Reply-To: <1b325703-b823-4304-9d9d-86071811e000@email.android.com> References: <1488301573.3046.9.camel@linux.vnet.ibm.com> <20170228105741.6253bb8a@xeon-e3> <1488325732.11610.9.camel@linux.vnet.ibm.com> <20170228172532.280811ed@xeon-e3> <1488349258.20321.11.camel@linux.vnet.ibm.com> <20170228224845.1da358ee@xeon-e3> <20170301155057.GA13167@lst.de> <20170301075412.2e5f1e98@xeon-e3> <20170302000135.GA22886@lst.de> <20170302005615.GA23687@lst.de> <20170301174058.383da142@xeon-e3> <20170302102324.47dbe3ad@xeon-e3> <895c4f2e-7faa-41e1-b5de-eedb4ae0f882@email.android.com> <20170302110505.6ad2eb61@xeon-e3> <1b325703-b823-4304-9d9d-86071811e000@email.android.com> MIME-Version: 1.0 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 Needs more testing but this does fix the observed problem. From: Stephen Hemminger Subject: [PATCH] hv_storvsc: fix error handling The Hyper-V storvsc SCSI driver was hiding all errors in INQUIRY and MODE_SENSE commands. This caused the scan process to incorrectly think devices were present and online. Also invalid LUN errors were not being handled correctly. This fixes problems booting a GEN2 VM on Hyper-V. It effectively reverts commit 4ed51a21c0f69 ("Staging: hv: storvsc: Fixup srb and scsi status for INQUIRY and MODE_SENSE") Signed-off-by: Stephen Hemminger --- drivers/scsi/storvsc_drv.c | 48 ++++------------------------------------------ 1 file changed, 4 insertions(+), 44 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 638e5f427c90..8cc241fc54b8 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -543,28 +543,6 @@ static void storvsc_host_scan(struct work_struct *work) kfree(wrk); } -static void storvsc_remove_lun(struct work_struct *work) -{ - struct storvsc_scan_work *wrk; - struct scsi_device *sdev; - - wrk = container_of(work, struct storvsc_scan_work, work); - if (!scsi_host_get(wrk->host)) - goto done; - - sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, wrk->lun); - - if (sdev) { - scsi_remove_device(sdev); - scsi_device_put(sdev); - } - scsi_host_put(wrk->host); - -done: - kfree(wrk); -} - - /* * We can get incoming messages from the host that are not in response to * messages that we have sent out. An example of this would be messages @@ -955,8 +933,7 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb, } break; case SRB_STATUS_INVALID_LUN: - do_work = true; - process_err_fn = storvsc_remove_lun; + set_host_byte(scmnd, DID_NO_CONNECT); break; case SRB_STATUS_ABORTED: if (vm_srb->srb_status & SRB_STATUS_AUTOSENSE_VALID && @@ -1050,32 +1027,15 @@ static void storvsc_on_io_completion(struct storvsc_device *stor_device, stor_pkt = &request->vstor_packet; - /* - * The current SCSI handling on the host side does - * not correctly handle: - * INQUIRY command with page code parameter set to 0x80 - * MODE_SENSE command with cmd[2] == 0x1c - * - * Setup srb and scsi status so this won't be fatal. - * We do this so we can distinguish truly fatal failues - * (srb status == 0x4) and off-line the device in that case. - */ - - if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) || - (stor_pkt->vm_srb.cdb[0] == MODE_SENSE)) { - vstor_packet->vm_srb.scsi_status = 0; - vstor_packet->vm_srb.srb_status = SRB_STATUS_SUCCESS; - } - - /* Copy over the status...etc */ stor_pkt->vm_srb.scsi_status = vstor_packet->vm_srb.scsi_status; stor_pkt->vm_srb.srb_status = vstor_packet->vm_srb.srb_status; stor_pkt->vm_srb.sense_info_length = vstor_packet->vm_srb.sense_info_length; - if (vstor_packet->vm_srb.scsi_status != 0 || - vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS) + if (stor_pkt->vm_srb.cdb[0] != INQUIRY && + (vstor_packet->vm_srb.scsi_status != 0 || + vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)) storvsc_log(device, STORVSC_LOGGING_WARN, "cmd 0x%x scsi status 0x%x srb status 0x%x\n", stor_pkt->vm_srb.cdb[0],