kernel/git/stable/linux.git/drivers/scsi/sd.c, branch linux-3.18.y

scsi: sd: Fix cache_type_store()

2019-01-26T08:44:25+00:00

commit 44759979a49bfd2d20d789add7fa81a21eb1a4ab upstream. Changing of caching mode via /sys/devices/.../scsi_disk/.../cache_type may fail if device responds to MODE SENSE command with DPOFUA flag set, and then checks this flag to be not set on MODE SELECT command. In this scenario, when trying to change cache_type, write always fails: # echo "none" >cache_type bash: echo: write error: Invalid argument And following appears in dmesg: [13007.865745] sd 1:0:1:0: [sda] Sense Key : Illegal Request [current] [13007.865753] sd 1:0:1:0: [sda] Add. Sense: Invalid field in parameter list From SBC-4 r15, 6.5.1 "Mode pages overview", description of DEVICE-SPECIFIC PARAMETER field in the mode parameter header: ... The write protect (WP) bit for mode data sent with a MODE SELECT command shall be ignored by the device server. ... The DPOFUA bit is reserved for mode data sent with a MODE SELECT command. ... The remaining bits in the DEVICE-SPECIFIC PARAMETER byte are also reserved and shall be set to zero. [mkp: shuffled commentary to commit description] Cc: stable@vger.kernel.org Signed-off-by: Ivan Mironov Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: sd: Keep disk read-only when re-reading partition

2018-05-30T05:47:36+00:00

[ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ] If the read-only flag is true on a SCSI disk, re-reading the partition table sets the flag back to false. To observe this bug, you can run: 1. blockdev --setro /dev/sda 2. blockdev --rereadpt /dev/sda 3. blockdev --getro /dev/sda This commit reads the disk's old state and combines it with the device disk-reported state rather than unconditionally marking it as RW. Reported-by: Li Ning Signed-off-by: Jeremy Cline Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

scsi: sd: Defer spinning up drive while SANITIZE is in progress

2018-05-02T14:59:55+00:00

commit 505aa4b6a8834a2300971c5220c380c3271ebde3 upstream. A drive being sanitized will return NOT READY / ASC 0x4 / ASCQ 0x1b ("LOGICAL UNIT NOT READY. SANITIZE IN PROGRESS"). Prevent spinning up the drive until this condition clears. [mkp: tweaked commit message] Signed-off-by: Mahesh Rajashekhara Cc: Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: sd: Fix capacity calculation with 32-bit sector_t

2017-04-22T05:14:58+00:00

commit 7c856152cb92f8eee2df29ef325a1b1f43161aff upstream. We previously made sure that the reported disk capacity was less than 0xffffffff blocks when the kernel was not compiled with large sector_t support (CONFIG_LBDAF). However, this check assumed that the capacity was reported in units of 512 bytes. Add a sanity check function to ensure that we only enable disks if the entire reported capacity can be expressed in terms of sector_t. Reported-by: Steve Magnani Cc: Bart Van Assche Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes

2016-04-20T05:27:31+00:00

[ Upstream commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a ] During revalidate we check whether device capacity has changed before we decide whether to output disk information or not. The check for old capacity failed to take into account that we scaled sdkp->capacity based on the reported logical block size. And therefore the capacity test would always fail for devices with sectors bigger than 512 bytes and we would print several copies of the same discovery information. Avoid scaling sdkp->capacity and instead adjust the value on the fly when setting the block device capacity and generating fake C/H/S geometry. Signed-off-by: Martin K. Petersen Cc: Reported-by: Hannes Reinecke Reviewed-by: Hannes Reinicke Reviewed-by: Ewan Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

SCSI: fix crashes in sd and sr runtime PM

2016-02-15T20:42:32+00:00

[ Upstream commit 13b4389143413a1f18127c07f72c74cad5b563e8 ] Runtime suspend during driver probe and removal can cause problems. The driver's runtime_suspend or runtime_resume callbacks may invoked before the driver has finished binding to the device or after the driver has unbound from the device. This problem shows up with the sd and sr drivers, and can cause disk or CD/DVD drives to become unusable as a result. The fix is simple. The drivers store a pointer to the scsi_disk or scsi_cd structure as their private device data when probing is finished, so we simply have to be sure to clear the private data during removal and test it during runtime suspend/resume. This fixes . Signed-off-by: Alan Stern Reported-by: Paul Menzel Reported-by: Erich Schubert Reported-by: Alexandre Rossi Tested-by: Paul Menzel Tested-by: Erich Schubert CC: Signed-off-by: James Bottomley Signed-off-by: Sasha Levin

sd: Fix maximum I/O size for BLOCK_PC requests

2015-09-17T05:30:44+00:00

[ Upstream commit 4f258a46346c03fa0bbb6199ffaf4e1f9f599660 ] Commit bcdb247c6b6a ("sd: Limit transfer length") clamped the maximum size of an I/O request to the MAXIMUM TRANSFER LENGTH field in the BLOCK LIMITS VPD. This had the unfortunate effect of also limiting the maximum size of non-filesystem requests sent to the device through sg/bsg. Avoid using blk_queue_max_hw_sectors() and set the max_sectors queue limit directly. Also update the comment in blk_limits_max_hw_sectors() to clarify that max_hw_sectors defines the limit for the I/O controller only. Signed-off-by: Martin K. Petersen Reported-by: Brian King Tested-by: Brian King Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: James Bottomley Signed-off-by: Sasha Levin

sd: Disable support for 256 byte/sector disks

2015-06-10T17:42:39+00:00

[ Upstream commit 74856fbf441929918c49ff262ace9835048e4e6a ] 256 bytes per sector support has been broken since 2.6.X, and no-one stepped up to fix this. So disable support for it. Signed-off-by: Mark Hounschell Signed-off-by: Hannes Reinecke Cc: stable@vger.kernel.org Signed-off-by: James Bottomley Signed-off-by: Sasha Levin

sd: Unregister integrity profile

2015-05-17T23:12:20+00:00

[ Upstream commit e727c42bd55794765c460b7ac2b6cc969f2a9698 ] The new integrity code did not correctly unregister the profile for SD disks. Call blk_integrity_unregister() when we release a disk. Signed-off-by: Martin K. Petersen Reported-by: Sagi Grimberg Tested-by: Sagi Grimberg Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: James Bottomley Signed-off-by: Sasha Levin

sd: Fix max transfer length for 4k disks

2015-02-11T07:00:51+00:00

commit 3a9794d32984b67a6d8992226918618f0e51e5d5 upstream. The following patch fixes an issue observed with 4k sector disks where the max_hw_sectors attribute was getting set too large in sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units of SCSI logical blocks and queue_max_hw_sectors is in units of 512 byte blocks, on a 4k sector disk, every time we went through sd_revalidate_disk, we were taking the current value of queue_max_hw_sectors and increasing it by a factor of 8. Fix this by only shifting sdkp->max_xfer_blocks. Signed-off-by: Brian King Reviewed-by: Paolo Bonzini Reviewed-by: Martin K. Petersen Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman