linux-kernel - 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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Mar 2017 22:14:37 +0000
From:   Stephen Hemminger <sthemmin@...rosoft.com>
To:     Joseph Salisbury <joseph.salisbury@...onical.com>,
        Long Li <longli@...rosoft.com>
CC:     KY Srinivasan <kys@...rosoft.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Greg KH <gregkh@...uxfoundation.org>
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

Are you sure the real problem is not the one fixed by this commit?

commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f
Author: Stephen Hemminger <stephen@...workplumber.org>
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 <sthemmin@...rosoft.com>
    Reviewed-by: K. Y. Srinivasan <kys@...rosoft.com>
    Reviewed-by: Christoph Hellwig <hch@....de>
    Signed-off-by: Martin K. Petersen <martin.petersen@...cle.com>

-----Original Message-----
From: Joseph Salisbury [mailto:joseph.salisbury@...onical.com] 
Sent: Monday, March 27, 2017 1:22 PM
To: Long Li <longli@...rosoft.com>
Cc: KY Srinivasan <kys@...rosoft.com>; Martin K. Petersen <martin.petersen@...cle.com>; Haiyang Zhang <haiyangz@...rosoft.com>; Stephen Hemminger <sthemmin@...rosoft.com>; jejb@...ux.vnet.ibm.com; devel@...uxdriverproject.org; linux-scsi <linux-scsi@...r.kernel.org>; LKML <linux-kernel@...r.kernel.org>; stable@...r.kernel.org; Greg KH <gregkh@...uxfoundation.org>
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 <longli@...rosoft.com>
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