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

scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

2018-01-01T20:50:55+00:00

commit 28a0bc4120d38a394499382ba21d6965a67a3703 upstream. SBC-4 states: "A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates the maximum number of LBAs that may be unmapped by an UNMAP command" "A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates the maximum number of contiguous logical blocks that the device server allows to be unmapped or written in a single WRITE SAME command." Despite the spec being clear on the topic, some devices incorrectly expect WRITE SAME commands with the UNMAP bit set to be limited to the value reported in MAXIMUM UNMAP LBA COUNT in the Block Limits VPD. Implement a blacklist option that can be used to accommodate devices with this behavior. Reported-by: Bill Kuzeja Reported-by: Ewan D. Milne Reviewed-by: Ewan D. Milne Tested-by: Laurence Oberman Signed-off-by: Martin K. Petersen [bwh: Backported to 3.2: - Keep using literals for SD_MAX_WS{16,10}_BLOCKS - Adjust context] Signed-off-by: Ben Hutchings

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

2017-07-18T17:38:41+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 [bwh: Backported to 3.2: use integer literal instead of U32_MAX] Signed-off-by: Ben Hutchings

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

2016-04-30T22:05:22+00:00

commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a upstream. 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 Reported-by: Hannes Reinecke Reviewed-by: Hannes Reinicke Reviewed-by: Ewan Milne Signed-off-by: Martin K. Petersen [bwh: Backported to 3.2: - logical_to_sectors() is a new function - Adjust context] Signed-off-by: Ben Hutchings

SCSI: fix crashes in sd and sr runtime PM

2016-02-27T14:28:44+00:00

commit 13b4389143413a1f18127c07f72c74cad5b563e8 upstream. 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 Signed-off-by: James Bottomley [bwh: Backported to 3.2: drop changes to sr as it doesn't support runtime PM] Signed-off-by: Ben Hutchings

sd: Disable support for 256 byte/sector disks

2015-08-06T23:32:12+00:00

commit 74856fbf441929918c49ff262ace9835048e4e6a upstream. 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 Signed-off-by: James Bottomley [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

usb-storage/SCSI: Add broken_fua blacklist flag

2014-08-06T17:07:33+00:00

commit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream. Some buggy JMicron USB-ATA bridges don't know how to translate the FUA bit in READs or WRITEs. This patch adds an entry in unusual_devs.h and a blacklist flag to tell the sd driver not to use FUA. Signed-off-by: Alan Stern Reported-by: Michael Büsch Tested-by: Michael Büsch Acked-by: James Bottomley CC: Matthew Dharm Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - Adjust context - Use sd_printk() not sd_first_printk()] Signed-off-by: Ben Hutchings

sd: Fix potential out-of-bounds access

2013-10-26T20:06:03+00:00

commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream. This patch fixes an out-of-bounds error in sd_read_cache_type(), found by Google's AddressSanitizer tool. When the loop ends, we know that "offset" lies beyond the end of the data in the buffer, so no Caching mode page was found. In theory it may be present, but the buffer size is limited to 512 bytes. Signed-off-by: Alan Stern Reported-by: Dmitry Vyukov Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

sd: fix crash when UA received on DIF enabled device

2013-08-02T20:15:05+00:00

commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream. sd_prep_fn will allocate a larger CDB for the command via mempool_alloc for devices using DIF type 2 protection. This CDB was being freed in sd_done, which results in a kernel crash if the command is retried due to a UNIT ATTENTION. This change moves the code to free the larger CDB into sd_unprep_fn instead, which is invoked after the request is complete. It is no longer necessary to call scsi_print_command separately for this case as the ->cmnd will no longer be NULL in the normal code path. Also removed conditional test for DIF type 2 when freeing the larger CDB because the protection_type could have been changed via sysfs while the command was executing. Signed-off-by: Ewan D. Milne Acked-by: Martin K. Petersen Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

sd: Fix parsing of 'temporary ' cache mode prefix

2013-07-27T04:34:19+00:00

commit 2ee3e26c673e75c05ef8b914f54fadee3d7b9c88 upstream. Commit 39c60a0948cc '[SCSI] sd: fix array cache flushing bug causing performance problems' added temp as a pointer to "temporary " and used sizeof(temp) - 1 as its length. But sizeof(temp) is the size of the pointer, not the size of the string constant. Change temp to a static array so that sizeof() does what was intended. Signed-off-by: Ben Hutchings Signed-off-by: James Bottomley

sd: fix array cache flushing bug causing performance problems

2013-07-27T04:34:19+00:00

commit 39c60a0948cc06139e2fbfe084f83cb7e7deae3b upstream. Some arrays synchronize their full non volatile cache when the sd driver sends a SYNCHRONIZE CACHE command. Unfortunately, they can have Terrabytes of this and we send a SYNCHRONIZE CACHE for every barrier if an array reports it has a writeback cache. This leads to massive slowdowns on journalled filesystems. The fix is to allow userspace to turn off the writeback cache setting as a temporary measure (i.e. without doing the MODE SELECT to write it back to the device), so even though the device reported it has a writeback cache, the user, knowing that the cache is non volatile and all they care about is filesystem correctness, can turn that bit off in the kernel and avoid the performance ruinous (and safety irrelevant) SYNCHRONIZE CACHE commands. The way you do this is add a 'temporary' prefix when performing the usual cache setting operations, so echo temporary write through > /sys/class/scsi_disk//cache_type Reported-by: Ric Wheeler Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings