From patchwork Sat Mar 4 21:03:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: KY Srinivasan X-Patchwork-Id: 9604255 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 CA8C1602B4 for ; Sat, 4 Mar 2017 21:04:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AF2992841A for ; Sat, 4 Mar 2017 21:04:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A1B6228428; Sat, 4 Mar 2017 21:04:41 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 94C2B2841A for ; Sat, 4 Mar 2017 21:04:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752276AbdCDVEf (ORCPT ); Sat, 4 Mar 2017 16:04:35 -0500 Received: from mail-co1nam03on0109.outbound.protection.outlook.com ([104.47.40.109]:48332 "EHLO NAM03-CO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752133AbdCDVEf (ORCPT ); Sat, 4 Mar 2017 16:04:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eHqlDC59M35qjzXto3Eaj1EYf7aTRMU6OKdJc2UPssQ=; b=N1Pz9A9dHQIcahZvaYZq2GCKJbhTSbI4VD9ZtsStxPJss5n5T+s0XXBsZ6MpyiixWaFZ6YW0MWmeCD10rqI9Np5deI7vN1A01wahqSv9BJ4hSnYKqyeXMfSK30aOQRGIUlQO/3RZTF/38e3vjutZSgb8NDeURAJ821WDj9iLq+I= Received: from DM5PR03MB2490.namprd03.prod.outlook.com (10.168.233.136) by DM5PR03MB2665.namprd03.prod.outlook.com (10.168.197.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Sat, 4 Mar 2017 21:03:41 +0000 Received: from DM5PR03MB2490.namprd03.prod.outlook.com ([10.168.233.136]) by DM5PR03MB2490.namprd03.prod.outlook.com ([10.168.233.136]) with mapi id 15.01.0947.015; Sat, 4 Mar 2017 21:03:42 +0000 From: KY Srinivasan To: Stephen Hemminger , James Bottomley CC: Hannes Reinecke , Christoph Hellwig , "James Bottomley" , Jens Axboe , "Linus Torvalds" , "Martin K. Petersen" , Dexuan Cui , Long Li , Josh Poulson , "Adrian Suhov (Cloudbase Solutions SRL)" , "linux-scsi@vger.kernel.org" , Haiyang Zhang Subject: RE: [RFC] hv_storvsc: error handling. Thread-Topic: [RFC] hv_storvsc: error handling. Thread-Index: AQHSlIFO0SkI7YXr5E+wsDj8AJ/5rqGE/jbg Date: Sat, 4 Mar 2017 21:03:41 +0000 Message-ID: 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> <20170303165011.53a38794@xeon-e3> In-Reply-To: <20170303165011.53a38794@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: networkplumber.org; dkim=none (message not signed) header.d=none;networkplumber.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8c00:1040:7415:79b8:a2c0:fe22] x-ms-office365-filtering-correlation-id: 12e94c2c-e383-443f-bd70-08d46341f038 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM5PR03MB2665; x-microsoft-exchange-diagnostics: 1; DM5PR03MB2665; 7:EmYfXZx5cmP94Lz/Mj/Gh+FYulwWyXSepAWaYuK61TVSRwo2yoVdUEzxDR0x82idMrgTVcSACY73XvwquxCAUAxFxdhUt8RA2CsZZRDpMvmYT3zJFOcdjyOJ3cICf8ItZLtUBL4NVBFV9gItq2nGhPX4PrGaXW1V4ARxMKMr1fswTtAh5KHh+tQDyn6RFUheKsVm0rYhIKhfYg+K9pdD17Ws9ag/W4ywSpATpw+eVcAmJtUaxFWO32vpdNXoavrEM7g7gcz0FEdiN+rS8Sgpo5aVZxwYewH1VcLlBKZTgwoz3n9q7xD8QHeWINr1gT2AUnl3q6dzJPYSxRd5pWrzPZRzCCTrhPenLlcrIZqTpXI= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(104084551191319)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(6042181); SRVR:DM5PR03MB2665; BCL:0; PCL:0; RULEID:; SRVR:DM5PR03MB2665; x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(77096006)(6506006)(6436002)(55016002)(99286003)(54906002)(2950100002)(5660300001)(7696004)(2900100001)(122556002)(102836003)(3660700001)(6116002)(25786008)(93886004)(229853002)(2906002)(3280700002)(92566002)(10290500002)(8676002)(53546006)(106116001)(5005710100001)(81166006)(8936002)(4326008)(8990500004)(38730400002)(107886003)(7736002)(86362001)(575784001)(6246003)(9686003)(10090500001)(50986999)(33656002)(54356999)(189998001)(76176999)(53936002)(305945005)(74316002)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2665; H:DM5PR03MB2490.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2017 21:03:41.8169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2665 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 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Friday, March 3, 2017 4:50 PM > To: James Bottomley > Cc: Hannes Reinecke ; Christoph Hellwig ; > James Bottomley ; Jens Axboe > ; Linus Torvalds ; > Martin K. Petersen ; KY Srinivasan > ; Dexuan Cui ; Long Li > ; Josh Poulson ; Adrian > Suhov (Cloudbase Solutions SRL) ; linux- > scsi@vger.kernel.org; Haiyang Zhang > Subject: [RFC] hv_storvsc: error handling. > > 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], > -- This patch gets rid of the ability to "hot remove" LUNs. I don't think that can be part of any solution. The INQUIRY hack I put in a long time ago was to deal with host bugs on prior versions of Windows server. WS2016 should not be trigerring this code. Stephen, could you please test this patch - a quick hack: From b97f24f224a71a6e745c42e5640045a553eb407c Mon Sep 17 00:00:00 2001 From: K. Y. Srinivasan Date: Sat, 4 Mar 2017 14:00:46 -0700 Subject: [PATCH 1/1] scsi: storvsc: Fix a bug in LUN removal code Reply-To: kys@microsoft.com Signed-off-by: K. Y. Srinivasan --- drivers/scsi/storvsc_drv.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) -- 1.7.1 > 2.11.0 > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 05526b7..27eb682 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -885,6 +885,7 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb, struct storvsc_scan_work *wrk; void (*process_err_fn)(struct work_struct *work); bool do_work = false; + struct scsi_device *sdev; switch (SRB_STATUS(vm_srb->srb_status)) { case SRB_STATUS_ERROR: @@ -911,6 +912,18 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb, } break; case SRB_STATUS_INVALID_LUN: + if (!scsi_host_get(host)) { + set_host_byte(scmnd, DID_NO_CONNECT); + break; + } + + sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, wrk->lun); + + if (!sdev) { + set_host_byte(scmnd, DID_NO_CONNECT); + break; + } + do_work = true; process_err_fn = storvsc_remove_lun; break;