Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752635AbdC0WO4 (ORCPT ); Mon, 27 Mar 2017 18:14:56 -0400 Received: from mail-bn3nam01on0131.outbound.protection.outlook.com ([104.47.33.131]:22643 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751968AbdC0WOs (ORCPT ); Mon, 27 Mar 2017 18:14:48 -0400 From: Stephen Hemminger To: Joseph Salisbury , Long Li CC: KY Srinivasan , "Martin K. Petersen" , Haiyang Zhang , "jejb@linux.vnet.ibm.com" , "devel@linuxdriverproject.org" , linux-scsi , LKML , "stable@vger.kernel.org" , Greg KH Subject: RE: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors Thread-Topic: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors Thread-Index: AQHSpzfVBcmfewnSnUKcX0kPzG79haGpP70w Date: Mon, 27 Mar 2017 22:14:37 +0000 Message-ID: References: <5df6cd65-92d5-e4c5-56e3-771643f86861@canonical.com> In-Reply-To: <5df6cd65-92d5-e4c5-56e3-771643f86861@canonical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: canonical.com; dkim=none (message not signed) header.d=none;canonical.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [204.195.18.65] x-microsoft-exchange-diagnostics: 1;BN3PR03MB2226;7:vhRiNsFd6Pz6xYTsPX7HSJEpfJkqEECMj6idX7ItkDAehK0T5uT/J5qPxDeJtCE+QKbfhyn5WlGcw5vM9a+mrUT+7JMVoyz/55o09IOK846cSnidibhn+A/RMgeMc0jvNsG4dJXvlzsqLpmHSzVvstUhrgHmkSS+oiuCIOjG2SmkuzRNGvI++TpxS8Id9oLDEHqboRvTApaB5g/7V4/45MEmOHJy4kP89prpR3tnhzHj2OfYr5R2McG6LYcGpaPEdW7VAAi0zz/3v+CRp3lcAAnXRmwDwjjs6b1UAezG9bLrpuS1Pnd+/o7g2hgn7iiIx99gr3JeJ6ZHtpGjplip9ePaqGNJGHDAJrAVYCBZrGY= x-ms-office365-filtering-correlation-id: 5c1eeb96-1585-4846-15a8-08d4755ea842 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081);SRVR:BN3PR03MB2226; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(9452136761055)(104084551191319)(146099531331640)(198206253151910); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148);SRVR:BN3PR03MB2226;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2226; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(377454003)(13464003)(54356999)(6306002)(76176999)(6246003)(50986999)(966004)(86362001)(5005710100001)(81166006)(9686003)(1720100001)(8936002)(53936002)(8676002)(54906002)(55016002)(2900100001)(99286003)(189998001)(6636002)(3660700001)(2950100002)(229853002)(2906002)(66066001)(25786009)(74316002)(53546009)(7736002)(305945005)(7696004)(33656002)(6436002)(122556002)(2421001)(10290500002)(53366004)(77096006)(53376002)(5660300001)(3280700002)(3846002)(102836003)(6506006)(38730400002)(4326008)(6116002)(10090945008);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR03MB2226;H:BLUPR0301MB2098.namprd03.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2017 22:14:37.4642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2226 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v2RMF3fm001484 Content-Length: 2964 Lines: 69 Are you sure the real problem is not the one fixed by this commit? commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f Author: Stephen Hemminger Date: Tue Mar 7 09:15:53 2017 -0800 scsi: storvsc: Workaround for virtual DVD SCSI version Hyper-V host emulation of SCSI for virtual DVD device reports SCSI version 0 (UNKNOWN) but is still capable of supporting REPORTLUN. Without this patch, a GEN2 Linux guest on Hyper-V will not boot 4.11 successfully with virtual DVD ROM device. What happens is that the SCSI scan process falls back to doing sequential probing by INQUIRY. But the storvsc driver has a previous workaround that masks/blocks all errors reports from INQUIRY (or MODE_SENSE) commands. This workaround causes the scan to then populate a full set of bogus LUN's on the target and then sends kernel spinning off into a death spiral doing block reads on the non-existent LUNs. By setting the correct blacklist flags, the target with the DVD device is scanned with REPORTLUN and that works correctly. Patch needs to go in current 4.11, it is safe but not necessary in older kernels. Signed-off-by: Stephen Hemminger Reviewed-by: K. Y. Srinivasan Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen -----Original Message----- From: Joseph Salisbury [mailto:joseph.salisbury@canonical.com] Sent: Monday, March 27, 2017 1:22 PM To: Long Li Cc: KY Srinivasan ; Martin K. Petersen ; Haiyang Zhang ; Stephen Hemminger ; jejb@linux.vnet.ibm.com; devel@linuxdriverproject.org; linux-scsi ; LKML ; stable@vger.kernel.org; Greg KH Subject: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors Hi Long Li, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit 40630f462824ee24bc00d692865c86c3828094e0 Author: Long Li Date: Wed Dec 14 18:46:03 2016 -0800 scsi: storvsc: properly set residual data length on errors The regression was introduced in mainline as of v4.11-rc1. It was also cc'd to stable and has landed in v3.12.y, v4.4.y, v4.9.y and v4.10.y. This regression seems pretty severe since it's preventing virtual machines from booting. It's affecting a couple of users so far. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Thanks, Joe [0] http://pad.lv/1674635