From 15de0de29f7ba5cce9699a8cc2344ca137beb25a Mon Sep 17 00:00:00 2001 From: Sreekanth Reddy Date: Thu, 12 Nov 2015 23:40:37 +0530 Subject: mpt3sas: Fix use sas_is_tlr_enabled API before enabling MPI2_SCSIIO_CONTROL_TLR_ON flag Before enabling MPI2_SCSIIO_CONTROL_TLR_ON flag in MPI SCSI IO request message, check whether TLR is enabled on the drive using 'sas_is_tlr_enabled' API. Actually in the driver code, driver is using below API's 1. sas_enable_tlr() - to enable the TLR 2. sas_disable_tlr() - to disable the TLR 3. sas_is_tlr_enabled() - to check whether TLR is enabled or not. but in scsih_qcmd() we have missed to use sas_is_tlr_enabled() API, instead we checking for TLR bit from flag field of driver's 'struct MPT3SAS_DEVIC' structure. which is corrected with this patch. Signed-off-by: Sreekanth Reddy Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index d95206b7e116..9ab77b06434d 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -3905,8 +3905,7 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd *scmd) * We do not expose raid functionality to upper layer for warpdrive. */ if (!ioc->is_warpdrive && !scsih_is_raid(&scmd->device->sdev_gendev) - && (sas_device_priv_data->flags & MPT_DEVICE_TLR_ON) && - scmd->cmd_len != 32) + && sas_is_tlr_enabled(scmd->device) && scmd->cmd_len != 32) mpi_control |= MPI2_SCSIIO_CONTROL_TLR_ON; smid = mpt3sas_base_get_smid_scsiio(ioc, ioc->scsi_io_cb_idx, scmd); -- cgit v1.2.3 From 78b7b80cf0abd5ea31d229300b11e9c3a97324ae Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Fri, 13 Nov 2015 17:23:23 +0300 Subject: mvsas: don't allow negative timeouts There is a static checker warning here because "val" is controlled by the user and we have a upper bound on it but allow negative numbers. "val" appears to be a timeout in usec so this bug probably means we have a longer timeout than we should. Let's fix this by changing "val" to unsigned. Signed-off-by: Dan Carpenter Reviewed-by: Jack Wang Signed-off-by: Martin K. Petersen --- drivers/scsi/mvsas/mv_init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c index 1960d956c671..b39fe6473a21 100644 --- a/drivers/scsi/mvsas/mv_init.c +++ b/drivers/scsi/mvsas/mv_init.c @@ -759,7 +759,7 @@ mvs_store_interrupt_coalescing(struct device *cdev, struct device_attribute *attr, const char *buffer, size_t size) { - int val = 0; + unsigned int val = 0; struct mvs_info *mvi = NULL; struct Scsi_Host *shost = class_to_shost(cdev); struct sas_ha_struct *sha = SHOST_TO_SAS_HA(shost); @@ -767,7 +767,7 @@ mvs_store_interrupt_coalescing(struct device *cdev, if (buffer == NULL) return size; - if (sscanf(buffer, "%d", &val) != 1) + if (sscanf(buffer, "%u", &val) != 1) return -EINVAL; if (val >= 0x10000) { -- cgit v1.2.3 From d8a080c3746c0b60905a88ca56e83a8239c184e0 Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Thu, 12 Nov 2015 12:43:38 +0300 Subject: hpsa: logical vs bitwise AND typo HPSA_DIAG_OPTS_DISABLE_RLD_CACHING is a mask and bitwise AND was intended here instead of logical &&. This bug is essentially harmless, it means that sometimes we don't print a warning message which we wanted to print. Fixes: c2adae44e916 ('hpsa: disable report lun data caching') Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Acked-by: Don Brace Signed-off-by: Martin K. Petersen --- drivers/scsi/hpsa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 6d4412359d23..bff95090e52a 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -8679,7 +8679,7 @@ static void hpsa_disable_rld_caching(struct ctlr_info *h) if ((rc != 0) || (c->err_info->CommandStatus != 0)) goto errout; - if (*options && HPSA_DIAG_OPTS_DISABLE_RLD_CACHING) + if (*options & HPSA_DIAG_OPTS_DISABLE_RLD_CACHING) goto out; errout: -- cgit v1.2.3 From 0874f8ec9b0a462cc8787b7bb4b7824a1690da10 Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Mon, 16 Nov 2015 15:26:51 -0800 Subject: qla2xxx: Fix rwlock recursion This patch fixes the following kernel bug: kernel:BUG: rwlock recursion on CPU#2, insmod/39333, ffff8803e998cb28 kernel: Call Trace: kernel: [] dump_stack+0x48/0x64 kernel: [] rwlock_bug+0x67/0x70 kernel: [] do_raw_write_lock+0x8a/0xa0 kernel: [] _raw_write_lock_irqsave+0x63/0x80 kernel: [] qla82xx_rd_32+0xe8/0x140 [qla2xxx] kernel: [] qla82xx_crb_win_lock+0x25/0x60 [qla2xxx] kernel: [] qla82xx_wr_32+0xf6/0x150 [qla2xxx] kernel: [] qla82xx_disable_intrs+0x50/0x80 [qla2xxx] kernel: [] qla82xx_reset_chip+0x1a/0x20 [qla2xxx] kernel: [] qla2x00_initialize_adapter+0x132/0x420 [qla2xxx] kernel: [] qla82xx_rd_32+0xe8/0x140 [qla2xxx] kernel: [] qla82xx_crb_win_lock+0x25/0x60 [qla2xxx] kernel: [] qla82xx_wr_32+0xf6/0x150 [qla2xxx] kernel: [] qla82xx_disable_intrs+0x50/0x80 [qla2xxx] kernel: [] qla82xx_reset_chip+0x1a/0x20 [qla2xxx] kernel: [] qla2x00_initialize_adapter+0x132/0x420 [qla2xxx] kernel: [] qla2x00_probe_one+0xefe/0x2130 [qla2xxx] kernel: [] local_pci_probe+0x4c/0xa0 kernel: [] pci_call_probe+0x83/0xa0 kernel: [] pci_device_probe+0x7f/0xb0 kernel: [] really_probe+0x133/0x390 kernel: [] driver_probe_device+0x59/0xd0 kernel: [] __driver_attach+0xa1/0xb0 kernel: [] bus_for_each_dev+0x8d/0xb0 kernel: [] driver_attach+0x1e/0x20 kernel: [] bus_add_driver+0x1d2/0x290 kernel: [] driver_register+0x60/0xe0 kernel: [] __pci_register_driver+0x64/0x70 kernel: [] qla2x00_module_init+0x1cb/0x21b [qla2xxx] kernel: [] do_one_initcall+0xad/0x1c0 kernel: [] do_init_module+0x69/0x210 kernel: [] load_module+0x5cc/0x750 kernel: [] SyS_init_module+0x92/0xc0 kernel: [] entry_SYSCALL_64_fastpath+0x12/0x6f Fixes: 8dfa4b5a9b44 ("qla2xxx: Fix sparse annotation") Signed-off-by: Bart Van Assche Reported-by: Himanshu Madhani Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Reviewed-by: Chad Dupuis Cc: Giridhar Malavali Cc: Xose Vazquez Perez Cc: stable # v4.3+ Signed-off-by: Martin K. Petersen --- drivers/scsi/qla2xxx/qla_nx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/qla2xxx/qla_nx.c b/drivers/scsi/qla2xxx/qla_nx.c index eb0cc5475c45..b6b4cfdd7620 100644 --- a/drivers/scsi/qla2xxx/qla_nx.c +++ b/drivers/scsi/qla2xxx/qla_nx.c @@ -433,7 +433,7 @@ qla82xx_pci_get_crb_addr_2M(struct qla_hw_data *ha, ulong off_in, if (off_in < QLA82XX_PCI_CRBSPACE) return -1; - *off_out = (void __iomem *)(off_in - QLA82XX_PCI_CRBSPACE); + off_in -= QLA82XX_PCI_CRBSPACE; /* Try direct map */ m = &crb_128M_2M_map[CRB_BLK(off_in)].sub_block[CRB_SUBBLK(off_in)]; @@ -443,6 +443,7 @@ qla82xx_pci_get_crb_addr_2M(struct qla_hw_data *ha, ulong off_in, return 0; } /* Not in direct map, use crb window */ + *off_out = (void __iomem *)off_in; return 1; } -- cgit v1.2.3 From 757b22f9d56fb4e510782b29da752824daddf3c8 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Mon, 16 Nov 2015 17:49:23 +0100 Subject: advansys: fix big-endian builds Building the advansys driver in a big-endian configuration such as ARM allmodconfig shows a warning: drivers/scsi/advansys.c: In function 'adv_build_req': include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer implicitly truncated to unsigned type [-Woverflow] #define __cpu_to_le32(x) ((__force __le32)__swab32((x))) drivers/scsi/advansys.c:7806:22: note: in expansion of macro 'cpu_to_le32' scsiqp->sense_len = cpu_to_le32(SCSI_SENSE_BUFFERSIZE); It turns out that the commit that introduced this used the cpu_to_le32() incorrectly on an 8-bit field, which results in the sense_len to always be set to zero, as the SCSI_SENSE_BUFFERSIZE value gets moved to upper byte of the 32-bit intermediate. This removes the cpu_to_le32() call to restore the original version. I found this only by looking at the compiler output and have not done a full review for possible further endianess bugs in the same driver. Signed-off-by: Arnd Bergmann Fixes: 811ddc057aac ("advansys: use DMA-API for mapping sense buffer") Reviewed-by: Hannes Reinecke Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Martin K. Petersen --- drivers/scsi/advansys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c index 4305178e4e01..1c1cd657c380 100644 --- a/drivers/scsi/advansys.c +++ b/drivers/scsi/advansys.c @@ -7803,7 +7803,7 @@ adv_build_req(struct asc_board *boardp, struct scsi_cmnd *scp, return ASC_BUSY; } scsiqp->sense_addr = cpu_to_le32(sense_addr); - scsiqp->sense_len = cpu_to_le32(SCSI_SENSE_BUFFERSIZE); + scsiqp->sense_len = SCSI_SENSE_BUFFERSIZE; /* Build ADV_SCSI_REQ_Q */ -- cgit v1.2.3 From a35bb4458e5e5c9dc19a0daa0629409285f3b25e Mon Sep 17 00:00:00 2001 From: Vitaly Kuznetsov Date: Thu, 19 Nov 2015 14:17:06 +0100 Subject: scsi: report 'INQUIRY result too short' once per host Some host adapters (e.g. Hyper-V storvsc) are known for not respecting the SPC-2/3/4 requirement for 'INQUIRY data (see table ...) shall contain at least 36 bytes'. As a result we get tons on 'scsi 0:7:1:1: scsi scan: INQUIRY result too short (5), using 36' messages on console. This can be problematic for slow consoles. Introduce short_inquiry flag in struct Scsi_Host to print the message once per host. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen --- drivers/scsi/scsi_scan.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index d01e423ef44b..403a63310fb1 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -702,9 +702,12 @@ static int scsi_probe_lun(struct scsi_device *sdev, unsigned char *inq_result, * strings. */ if (sdev->inquiry_len < 36) { - sdev_printk(KERN_INFO, sdev, - "scsi scan: INQUIRY result too short (%d)," - " using 36\n", sdev->inquiry_len); + if (!sdev->host->short_inquiry) { + shost_printk(KERN_INFO, sdev->host, + "scsi scan: INQUIRY result too short (%d)," + " using 36\n", sdev->inquiry_len); + sdev->host->short_inquiry = 1; + } sdev->inquiry_len = 36; } -- cgit v1.2.3 From ab08ee14393724ab52b92be643d588d41a1a05be Mon Sep 17 00:00:00 2001 From: Maurizio Lombardi Date: Wed, 18 Nov 2015 15:32:44 +0100 Subject: st: fix potential null pointer dereference. If cdev_add() returns an error, the code calls cdev_del() passing the STm->cdevs[rew] pointer as parameter; the problem is that the pointer has not been initialized yet. This patch fixes the problem by moving the STm->cdevs[rew] pointer initialization before the call to cdev_add(). It also sets STm->devs[rew] and STm->cdevs[rew] to NULL in case of failure. Signed-off-by: Maurizio Lombardi Reviewed-by: Johannes Thumshirn Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen --- drivers/scsi/st.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c index b37b9b00c4b4..3e79c80bf6c6 100644 --- a/drivers/scsi/st.c +++ b/drivers/scsi/st.c @@ -4083,6 +4083,7 @@ static int create_one_cdev(struct scsi_tape *tape, int mode, int rew) } cdev->owner = THIS_MODULE; cdev->ops = &st_fops; + STm->cdevs[rew] = cdev; error = cdev_add(cdev, cdev_devno, 1); if (error) { @@ -4091,7 +4092,6 @@ static int create_one_cdev(struct scsi_tape *tape, int mode, int rew) pr_err("st%d: Device not attached.\n", dev_num); goto out_free; } - STm->cdevs[rew] = cdev; i = mode << (4 - ST_NBR_MODE_BITS); snprintf(name, 10, "%s%s%s", rew ? "n" : "", @@ -4110,8 +4110,9 @@ static int create_one_cdev(struct scsi_tape *tape, int mode, int rew) return 0; out_free: cdev_del(STm->cdevs[rew]); - STm->cdevs[rew] = NULL; out: + STm->cdevs[rew] = NULL; + STm->devs[rew] = NULL; return error; } -- cgit v1.2.3 From be821fd8e62765de43cc4f0e2db363d0e30a7e9b Mon Sep 17 00:00:00 2001 From: Vitaly Kuznetsov Date: Thu, 19 Nov 2015 14:02:19 +0100 Subject: scsi_sysfs: protect against double execution of __scsi_remove_device() On some host errors storvsc module tries to remove sdev by scheduling a job which does the following: sdev = scsi_device_lookup(wrk->host, 0, 0, wrk->lun); if (sdev) { scsi_remove_device(sdev); scsi_device_put(sdev); } While this code seems correct the following crash is observed: general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC RIP: 0010:[] [] bdi_destroy+0x39/0x220 ... [] ? _raw_spin_unlock_irq+0x2c/0x40 [] blk_cleanup_queue+0x17b/0x270 [] __scsi_remove_device+0x54/0xd0 [scsi_mod] [] scsi_remove_device+0x2b/0x40 [scsi_mod] [] storvsc_remove_lun+0x3d/0x60 [hv_storvsc] [] process_one_work+0x1b1/0x530 ... The problem comes with the fact that many such jobs (for the same device) are being scheduled simultaneously. While scsi_remove_device() uses shost->scan_mutex and scsi_device_lookup() will fail for a device in SDEV_DEL state there is no protection against someone who did scsi_device_lookup() before we actually entered __scsi_remove_device(). So the whole scenario looks like that: two callers do simultaneous (or preemption happens) calls to scsi_device_lookup() ant these calls succeed for both of them, after that they try doing scsi_remove_device(). shost->scan_mutex only serializes their calls to __scsi_remove_device() and we end up doing the cleanup path twice. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen --- drivers/scsi/scsi_sysfs.c | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 8b7fa8aece66..ed9182899f76 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1100,6 +1100,14 @@ void __scsi_remove_device(struct scsi_device *sdev) { struct device *dev = &sdev->sdev_gendev; + /* + * This cleanup path is not reentrant and while it is impossible + * to get a new reference with scsi_device_get() someone can still + * hold a previously acquired one. + */ + if (sdev->sdev_state == SDEV_DEL) + return; + if (sdev->is_visible) { if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0) return; -- cgit v1.2.3 From 2b8bbdb9d0ca1f968817dc1e9ede2c8940e5b7a4 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 19 Nov 2015 15:22:23 +0100 Subject: scsi: advansys needs ISA dma api for ISA support The advansys drvier uses the request_dma function that is used on ISA machines for the internal DMA controller, which causes build errors on platforms that have ISA slots but do not provide the ISA DMA API: drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:11300:10: error: implicit declaration of function 'request_dma' [-Werror=implicit-function-declaration] The problem now showed up in ARM randconfig builds after commit 6571fb3f8b7f ("advansys: Update to version 3.5 and remove compilation warning") made it possible to build on platforms that have neither VIRT_TO_BUS nor ISA_DMA_API but that do have ISA. This adds the missing dependency. Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen --- drivers/scsi/Kconfig | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 8aed855dd391..528cc7f3c01b 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -506,6 +506,7 @@ config SCSI_ADVANSYS tristate "AdvanSys SCSI support" depends on SCSI depends on ISA || EISA || PCI + depends on ISA_DMA_API || !ISA help This is a driver for all SCSI host adapters manufactured by AdvanSys. It is documented in the kernel source in -- cgit v1.2.3 From 653cfb85fbe73be44fda14bb67f1b95818bfc37f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 19 Nov 2015 23:04:35 +0100 Subject: scsi: hpsa: select CONFIG_SCSI_SAS_ATTR The hpsa driver recently started using the sas transport class, but it does not ensure that the corresponding code is actually built, which may lead to a link error: drivers/built-in.o: In function `hpsa_free_sas_phy': (.text+0x1ce874): undefined reference to `sas_port_delete_phy' (.text+0x1ce87c): undefined reference to `sas_phy_free' drivers/built-in.o: In function `hpsa_alloc_sas_port': (.text+0x1ceb9c): undefined reference to `sas_port_alloc_num' (.text+0x1ceba8): undefined reference to `sas_port_add' drivers/built-in.o: In function `hpsa_init': (.init.text+0x8838): undefined reference to `sas_attach_transport' (.init.text+0x8868): undefined reference to `sas_release_transport This adds 'select SCSI_SAS_ATTR' in the Kconfig entry, just like we do for all other drivers using those functions. Signed-off-by: Arnd Bergmann Fixes: d04e62b9d63a ("hpsa: add in sas transport class") Reviewed-by: Christoph Hellwig Acked-by: Don Brace Signed-off-by: Martin K. Petersen --- drivers/scsi/Kconfig | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 528cc7f3c01b..e0d29241fbb2 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -371,6 +371,7 @@ config SCSI_HPSA tristate "HP Smart Array SCSI driver" depends on PCI && SCSI select CHECK_SIGNATURE + select SCSI_SAS_ATTRS help This driver supports HP Smart Array Controllers (circa 2009). It is a SCSI alternative to the cciss driver, which is a block -- cgit v1.2.3 From 397737223c59e89dca7305feb6528caef8fbef84 Mon Sep 17 00:00:00 2001 From: "Martin K. Petersen" Date: Fri, 13 Nov 2015 16:46:47 -0500 Subject: sd: Make discard granularity match logical block size when LBPRZ=1 A device may report an OPTIMAL UNMAP GRANULARITY and UNMAP GRANULARITY ALIGNMENT in the Block Limits VPD. These parameters describe the device's internal provisioning allocation units. By default the block layer will round and align any discard requests based on these limits. If a device reports LBPRZ=1 to guarantee zeroes after discard, however, it is imperative that the block layer does not leave out any parts of the requested block range. Otherwise the device can not do the required zeroing of any partial allocation units and this can lead to data corruption. Since the dm thinp personality relies on the block layer's current behavior and is unable to deal with partial discard blocks we work around the problem by setting the granularity to match the logical block size when LBPRZ is enabled. Signed-off-by: Martin K. Petersen Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen --- drivers/scsi/sd.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index f7247778c225..e868d39c39bb 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -637,11 +637,24 @@ static void sd_config_discard(struct scsi_disk *sdkp, unsigned int mode) unsigned int max_blocks = 0; q->limits.discard_zeroes_data = 0; - q->limits.discard_alignment = sdkp->unmap_alignment * - logical_block_size; - q->limits.discard_granularity = - max(sdkp->physical_block_size, - sdkp->unmap_granularity * logical_block_size); + + /* + * When LBPRZ is reported, discard alignment and granularity + * must be fixed to the logical block size. Otherwise the block + * layer will drop misaligned portions of the request which can + * lead to data corruption. If LBPRZ is not set, we honor the + * device preference. + */ + if (sdkp->lbprz) { + q->limits.discard_alignment = 0; + q->limits.discard_granularity = 1; + } else { + q->limits.discard_alignment = sdkp->unmap_alignment * + logical_block_size; + q->limits.discard_granularity = + max(sdkp->physical_block_size, + sdkp->unmap_granularity * logical_block_size); + } sdkp->provisioning_mode = mode; -- cgit v1.2.3 From f7f9f26b139e53d798ea76465223a5f237d90fd3 Mon Sep 17 00:00:00 2001 From: Douglas Gilbert Date: Sun, 22 Nov 2015 12:11:28 -0500 Subject: scsi_debug: fix prevent_allow+verify regressions Ruediger Meier observed a regression with the PREVENT ALLOW MEDIUM REMOVAL command in lk 3.19: http://www.spinics.net/lists/util-linux-ng/msg11448.html Inspection indicated the same regression with VERIFY(10). The patch is against lk 3.19.3 and also works with lk 4.3.0 . With this patch both commands are accepted and do nothing. ChangeLog: - fix the lk 3.19 regression so that the PREVENT ALLOW MEDIUM REMOVAL command is supported once again - same fix for VERIFY(10) Signed-off-by: Douglas Gilbert Reviewed-by: Hannes Reinicke Reviewed-by: Ewan Milne Signed-off-by: Martin K. Petersen --- drivers/scsi/scsi_debug.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c index dfcc45bb03b1..d09d60293c27 100644 --- a/drivers/scsi/scsi_debug.c +++ b/drivers/scsi/scsi_debug.c @@ -465,8 +465,9 @@ static const struct opcode_info_t opcode_info_arr[SDEB_I_LAST_ELEMENT + 1] = { 0} }, {0, 0, 0, F_INV_OP | FF_RESPOND, NULL, NULL, /* MAINT OUT */ {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} }, - {0, 0, 0, F_INV_OP | FF_RESPOND, NULL, NULL, /* VERIFY */ - {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} }, + {0, 0x2f, 0, F_D_OUT_MAYBE | FF_DIRECT_IO, NULL, NULL, /* VERIFY(10) */ + {10, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xc7, + 0, 0, 0, 0, 0, 0} }, {1, 0x7f, 0x9, F_SA_HIGH | F_D_IN | FF_DIRECT_IO, resp_read_dt0, vl_iarr, {32, 0xc7, 0, 0, 0, 0, 0x1f, 0x18, 0x0, 0x9, 0xfe, 0, 0xff, 0xff, 0xff, 0xff} },/* VARIABLE LENGTH, READ(32) */ @@ -477,8 +478,8 @@ static const struct opcode_info_t opcode_info_arr[SDEB_I_LAST_ELEMENT + 1] = { {10, 0x13, 0xff, 0xff, 0, 0, 0, 0xff, 0xff, 0xc7, 0, 0, 0, 0, 0, 0} }, /* 20 */ - {0, 0, 0, F_INV_OP | FF_RESPOND, NULL, NULL, /* ALLOW REMOVAL */ - {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} }, + {0, 0x1e, 0, 0, NULL, NULL, /* ALLOW REMOVAL */ + {6, 0, 0, 0, 0x3, 0xc7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} }, {0, 0x1, 0, 0, resp_start_stop, NULL, /* REWIND ?? */ {6, 0x1, 0, 0, 0, 0xc7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} }, {0, 0, 0, F_INV_OP | FF_RESPOND, NULL, NULL, /* ATA_PT */ -- cgit v1.2.3 From ca369d51b3e1649be4a72addd6d6a168cfb3f537 Mon Sep 17 00:00:00 2001 From: "Martin K. Petersen" Date: Fri, 13 Nov 2015 16:46:48 -0500 Subject: block/sd: Fix device-imposed transfer length limits Commit 4f258a46346c ("sd: Fix maximum I/O size for BLOCK_PC requests") had the unfortunate side-effect of removing an implicit clamp to BLK_DEF_MAX_SECTORS for REQ_TYPE_FS requests in the block layer code. This caused problems for some SMR drives. Debugging this issue revealed a few problems with the existing infrastructure since the block layer didn't know how to deal with device-imposed limits, only limits set by the I/O controller. - Introduce a new queue limit, max_dev_sectors, which is used by the ULD to signal the maximum sectors for a REQ_TYPE_FS request. - Ensure that max_dev_sectors is correctly stacked and taken into account when overriding max_sectors through sysfs. - Rework sd_read_block_limits() so it saves the max_xfer and opt_xfer values for later processing. - In sd_revalidate() set the queue's max_dev_sectors based on the MAXIMUM TRANSFER LENGTH value in the Block Limits VPD. If this value is not reported, fall back to a cap based on the CDB TRANSFER LENGTH field size. - In sd_revalidate(), use OPTIMAL TRANSFER LENGTH from the Block Limits VPD--if reported and sane--to signal the preferred device transfer size for FS requests. Otherwise use BLK_DEF_MAX_SECTORS. - blk_limits_max_hw_sectors() is no longer used and can be removed. Signed-off-by: Martin K. Petersen Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93581 Reviewed-by: Christoph Hellwig Tested-by: sweeneygj@gmx.com Tested-by: Arzeets Tested-by: David Eisner Tested-by: Mario Kicherer Signed-off-by: Martin K. Petersen --- drivers/scsi/sd.c | 46 ++++++++++++++++++++++++++++++---------------- drivers/scsi/sd.h | 1 + 2 files changed, 31 insertions(+), 16 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index e868d39c39bb..7af47ed10d90 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2238,11 +2238,8 @@ got_data: } } - if (sdkp->capacity > 0xffffffff) { + if (sdkp->capacity > 0xffffffff) sdp->use_16_for_rw = 1; - sdkp->max_xfer_blocks = SD_MAX_XFER_BLOCKS; - } else - sdkp->max_xfer_blocks = SD_DEF_XFER_BLOCKS; /* Rescale capacity to 512-byte units */ if (sector_size == 4096) @@ -2559,7 +2556,6 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) { unsigned int sector_sz = sdkp->device->sector_size; const int vpd_len = 64; - u32 max_xfer_length; unsigned char *buffer = kmalloc(vpd_len, GFP_KERNEL); if (!buffer || @@ -2567,14 +2563,11 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) scsi_get_vpd_page(sdkp->device, 0xb0, buffer, vpd_len)) goto out; - max_xfer_length = get_unaligned_be32(&buffer[8]); - if (max_xfer_length) - sdkp->max_xfer_blocks = max_xfer_length; - blk_queue_io_min(sdkp->disk->queue, get_unaligned_be16(&buffer[6]) * sector_sz); - blk_queue_io_opt(sdkp->disk->queue, - get_unaligned_be32(&buffer[12]) * sector_sz); + + sdkp->max_xfer_blocks = get_unaligned_be32(&buffer[8]); + sdkp->opt_xfer_blocks = get_unaligned_be32(&buffer[12]); if (buffer[3] == 0x3c) { unsigned int lba_count, desc_count; @@ -2723,6 +2716,11 @@ static int sd_try_extended_inquiry(struct scsi_device *sdp) return 0; } +static inline u32 logical_to_sectors(struct scsi_device *sdev, u32 blocks) +{ + return blocks << (ilog2(sdev->sector_size) - 9); +} + /** * sd_revalidate_disk - called the first time a new disk is seen, * performs disk spin up, read_capacity, etc. @@ -2732,8 +2730,9 @@ static int sd_revalidate_disk(struct gendisk *disk) { struct scsi_disk *sdkp = scsi_disk(disk); struct scsi_device *sdp = sdkp->device; + struct request_queue *q = sdkp->disk->queue; unsigned char *buffer; - unsigned int max_xfer; + unsigned int dev_max, rw_max; SCSI_LOG_HLQUEUE(3, sd_printk(KERN_INFO, sdkp, "sd_revalidate_disk\n")); @@ -2781,11 +2780,26 @@ static int sd_revalidate_disk(struct gendisk *disk) */ sd_set_flush_flag(sdkp); - max_xfer = sdkp->max_xfer_blocks; - max_xfer <<= ilog2(sdp->sector_size) - 9; + /* Initial block count limit based on CDB TRANSFER LENGTH field size. */ + dev_max = sdp->use_16_for_rw ? SD_MAX_XFER_BLOCKS : SD_DEF_XFER_BLOCKS; + + /* Some devices report a maximum block count for READ/WRITE requests. */ + dev_max = min_not_zero(dev_max, sdkp->max_xfer_blocks); + q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max); + + /* + * Use the device's preferred I/O size for reads and writes + * unless the reported value is unreasonably large (or garbage). + */ + if (sdkp->opt_xfer_blocks && sdkp->opt_xfer_blocks <= dev_max && + sdkp->opt_xfer_blocks <= SD_DEF_XFER_BLOCKS) + rw_max = q->limits.io_opt = + logical_to_sectors(sdp, sdkp->opt_xfer_blocks); + else + rw_max = BLK_DEF_MAX_SECTORS; - sdkp->disk->queue->limits.max_sectors = - min_not_zero(queue_max_hw_sectors(sdkp->disk->queue), max_xfer); + /* Combine with controller limits */ + q->limits.max_sectors = min(rw_max, queue_max_hw_sectors(q)); set_capacity(disk, sdkp->capacity); sd_config_write_same(sdkp); diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h index 63ba5ca7f9a1..5f2a84aff29f 100644 --- a/drivers/scsi/sd.h +++ b/drivers/scsi/sd.h @@ -67,6 +67,7 @@ struct scsi_disk { atomic_t openers; sector_t capacity; /* size in 512-byte sectors */ u32 max_xfer_blocks; + u32 opt_xfer_blocks; u32 max_ws_blocks; u32 max_unmap_blocks; u32 unmap_granularity; -- cgit v1.2.3 From 3786dc454fa4c10b129acc0535705f1c5a64fc72 Mon Sep 17 00:00:00 2001 From: Himanshu Madhani Date: Tue, 24 Nov 2015 12:20:15 -0500 Subject: qla2xxx: Fix regression introduced by target configFS changes this patch fixes following regression # targetcli [Errno 13] Permission denied: '/sys/kernel/config/target/qla2xxx/21:00:00:0e:1e:08:c7:20/tpgt_1/enable' Fixes: 2eafd72939fd ("target: use per-attribute show and store methods") Signed-off-by: Himanshu Madhani Signed-off-by: Giridhar Malavali Reviewed-by: Christoph Hellwig Signed-off-by: Nicholas Bellinger --- drivers/scsi/qla2xxx/tcm_qla2xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c b/drivers/scsi/qla2xxx/tcm_qla2xxx.c index 3ba2e9564b9a..81af294f15a7 100644 --- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c +++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c @@ -902,7 +902,7 @@ static ssize_t tcm_qla2xxx_tpg_fabric_prot_type_show(struct config_item *item, return sprintf(page, "%d\n", tpg->tpg_attrib.fabric_prot_type); } -CONFIGFS_ATTR_WO(tcm_qla2xxx_tpg_, enable); +CONFIGFS_ATTR(tcm_qla2xxx_tpg_, enable); CONFIGFS_ATTR_RO(tcm_qla2xxx_tpg_, dynamic_sessions); CONFIGFS_ATTR(tcm_qla2xxx_tpg_, fabric_prot_type); -- cgit v1.2.3 From b49493f99690c8eaacfbc635bafaad629ea2c036 Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Wed, 18 Nov 2015 14:56:36 -0800 Subject: Fix a memory leak in scsi_host_dev_release() Avoid that kmemleak reports the following memory leak if a SCSI LLD calls scsi_host_alloc() and scsi_host_put() but neither scsi_host_add() nor scsi_host_remove(). The following shell command triggers that scenario: for ((i=0; i<2; i++)); do srp_daemon -oac | while read line; do echo $line >/sys/class/infiniband_srp/srp-mlx4_0-1/add_target done done unreferenced object 0xffff88021b24a220 (size 8): comm "srp_daemon", pid 56421, jiffies 4295006762 (age 4240.750s) hex dump (first 8 bytes): 68 6f 73 74 35 38 00 a5 host58.. backtrace: [] kmemleak_alloc+0x7a/0xc0 [] __kmalloc_track_caller+0xfe/0x160 [] kvasprintf+0x5b/0x90 [] kvasprintf_const+0x8d/0xb0 [] kobject_set_name_vargs+0x3c/0xa0 [] dev_set_name+0x3c/0x40 [] scsi_host_alloc+0x327/0x4b0 [] srp_create_target+0x4e/0x8a0 [ib_srp] [] dev_attr_store+0x1b/0x20 [] sysfs_kf_write+0x4a/0x60 [] kernfs_fop_write+0x14e/0x180 [] __vfs_write+0x2f/0xf0 [] vfs_write+0xa4/0x100 [] SyS_write+0x54/0xc0 [] entry_SYSCALL_64_fastpath+0x12/0x6f Signed-off-by: Bart Van Assche Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Reviewed-by: Sagi Grimberg Reviewed-by: Lee Duncan Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: stable Signed-off-by: Martin K. Petersen --- drivers/scsi/hosts.c | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index 8bb173e01084..7d647a32f85e 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -326,6 +326,17 @@ static void scsi_host_dev_release(struct device *dev) kfree(queuedata); } + if (shost->shost_state == SHOST_CREATED) { + /* + * Free the shost_dev device name here if scsi_host_alloc() + * and scsi_host_put() have been called but neither + * scsi_host_add() nor scsi_host_remove() has been called. + * This avoids that the memory allocated for the shost_dev + * name is leaked. + */ + kfree(dev_name(&shost->shost_dev)); + } + scsi_destroy_command_freelist(shost); if (shost_use_blk_mq(shost)) { if (shost->tag_set.tags) -- cgit v1.2.3 From b840c3627b6f4f856b333a14a72f8ed86da2f86c Mon Sep 17 00:00:00 2001 From: "Martin K. Petersen" Date: Mon, 30 Nov 2015 20:36:08 -0500 Subject: mpt3sas: Add dummy Kconfig option for backwards compatibility The mpt2sas driver was recently folded into mpt3sas to reduce code duplication. To avoid problems for people that only have CONFIG_SCSI_MPT2SAS in their .config we introduce a dummy option that will select MPT3SAS if MPT2SAS was previously enabled. This is a temporary measure and we will deprecate this config option in 4.6. Reported-by: Peter Zijlstra Acked-by: Christoph Hellwig Acked-by: James Bottomley CC: Ingo Molnar Signed-off-by: Martin K. Petersen --- drivers/scsi/mpt3sas/Kconfig | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/mpt3sas/Kconfig b/drivers/scsi/mpt3sas/Kconfig index 29061467cc17..25dc38f25ec6 100644 --- a/drivers/scsi/mpt3sas/Kconfig +++ b/drivers/scsi/mpt3sas/Kconfig @@ -71,3 +71,11 @@ config SCSI_MPT3SAS_MAX_SGE MAX_PHYS_SEGMENTS in most kernels. However in SuSE kernels this can be 256. However, it may decreased down to 16. Decreasing this parameter will reduce memory requirements on a per controller instance. + +config SCSI_MPT2SAS + tristate "Legacy MPT2SAS config option" + default n + select SCSI_MPT3SAS + ---help--- + Dummy config option for backwards compatiblity: configure the MPT3SAS + driver instead. -- cgit v1.2.3 From e619e6cbecb7fe97a924d625e848605333457b13 Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Fri, 20 Nov 2015 14:11:01 -0800 Subject: Revert "scsi: Fix a bdi reregistration race" The SCSI sd driver probes SCSI devices asynchronously. The sd_remove() function, called indirectly by device_del(), waits until asynchronous probing has finished. Since the block layer queue must only be cleaned up after probing has finished, device_del() has to be called before blk_cleanup_queue(). Hence revert commit bf2cf3baa20b. Signed-off-by: Bart Van Assche Cc: Signed-off-by: James Bottomley --- drivers/scsi/scsi_sysfs.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 8d2312239ae0..f5ace2bfc6db 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1110,7 +1110,9 @@ void __scsi_remove_device(struct scsi_device *sdev) device_unregister(&sdev->sdev_dev); transport_remove_device(dev); scsi_dh_remove_device(sdev); - } + device_del(dev); + } else + put_device(&sdev->sdev_dev); /* * Stop accepting new requests and wait until all queuecommand() and @@ -1121,16 +1123,6 @@ void __scsi_remove_device(struct scsi_device *sdev) blk_cleanup_queue(sdev->request_queue); cancel_work_sync(&sdev->requeue_work); - /* - * Remove the device after blk_cleanup_queue() has been called such - * a possible bdi_register() call with the same name occurs after - * blk_cleanup_queue() has called bdi_destroy(). - */ - if (sdev->is_visible) - device_del(dev); - else - put_device(&sdev->sdev_dev); - if (sdev->host->hostt->slave_destroy) sdev->host->hostt->slave_destroy(sdev); transport_destroy_device(dev); -- cgit v1.2.3 From 3ddda3e4c82dea58933bde8d0f6ef34470c360cb Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Wed, 2 Dec 2015 13:36:58 -0800 Subject: mpt3sas: fix Kconfig dependency problem for mpt2sas back compatibility The non-PCI builds of the O day test project are failing: On Thu, 2015-12-03 at 05:02 +0800, kbuild test robot wrote: > warning: (SCSI_MPT2SAS) selects SCSI_MPT3SAS which has unmet direct > dependencies (SCSI_LOWLEVEL && PCI && SCSI) The problem is that select and depend don't interact because Kconfig doesn't have a SAT solver, so depend picks up dependencies and select does onward selects, but select doesn't pick up dependencies. To fix this, we need to add the correct dependencies to the MPT2SAS option like this. Reported-by: kbuild test robot Fixes: b840c3627b6f4f856b333a14a72f8ed86da2f86c Signed-off-by: James Bottomley --- drivers/scsi/mpt3sas/Kconfig | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/mpt3sas/Kconfig b/drivers/scsi/mpt3sas/Kconfig index 25dc38f25ec6..b736dbc80485 100644 --- a/drivers/scsi/mpt3sas/Kconfig +++ b/drivers/scsi/mpt3sas/Kconfig @@ -76,6 +76,7 @@ config SCSI_MPT2SAS tristate "Legacy MPT2SAS config option" default n select SCSI_MPT3SAS + depends on PCI && SCSI ---help--- Dummy config option for backwards compatiblity: configure the MPT3SAS driver instead. -- cgit v1.2.3 From 3417c1b5cb1fdc10261dbed42b05cc93166a78fd Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Tue, 8 Dec 2015 09:00:31 -0800 Subject: ses: Fix problems with simple enclosures Simple enclosure implementations (mostly USB) are allowed to return only page 8 to every diagnostic query. That really confuses our implementation because we assume the return is the page we asked for and end up doing incorrect offsets based on bogus information leading to accesses outside of allocated ranges. Fix that by checking the page code of the return and giving an error if it isn't the one we asked for. This should fix reported bugs with USB storage by simply refusing to attach to enclosures that behave like this. It's also good defensive practise now that we're starting to see more USB enclosures. Reported-by: Andrea Gelmini Cc: stable@vger.kernel.org Reviewed-by: Ewan D. Milne Reviewed-by: Tomas Henzl Signed-off-by: James Bottomley --- drivers/scsi/ses.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c index dcb0d76d7312..7d9cec50b77d 100644 --- a/drivers/scsi/ses.c +++ b/drivers/scsi/ses.c @@ -84,6 +84,7 @@ static void init_device_slot_control(unsigned char *dest_desc, static int ses_recv_diag(struct scsi_device *sdev, int page_code, void *buf, int bufflen) { + int ret; unsigned char cmd[] = { RECEIVE_DIAGNOSTIC, 1, /* Set PCV bit */ @@ -92,9 +93,26 @@ static int ses_recv_diag(struct scsi_device *sdev, int page_code, bufflen & 0xff, 0 }; + unsigned char recv_page_code; - return scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buf, bufflen, + ret = scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buf, bufflen, NULL, SES_TIMEOUT, SES_RETRIES, NULL); + if (unlikely(!ret)) + return ret; + + recv_page_code = ((unsigned char *)buf)[0]; + + if (likely(recv_page_code == page_code)) + return ret; + + /* successful diagnostic but wrong page code. This happens to some + * USB devices, just print a message and pretend there was an error */ + + sdev_printk(KERN_ERR, sdev, + "Wrong diagnostic page; asked for %d got %u\n", + page_code, recv_page_code); + + return -EINVAL; } static int ses_send_diag(struct scsi_device *sdev, int page_code, -- cgit v1.2.3 From 1c69d3b6eb73e466ecbb8edaf1bc7fd585b288da Mon Sep 17 00:00:00 2001 From: Ken Xue Date: Tue, 1 Dec 2015 14:45:23 +0800 Subject: Revert "SCSI: Fix NULL pointer dereference in runtime PM" This reverts commit 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime PM") The old commit may lead to a issue that blk_{pre|post}_runtime_suspend and blk_{pre|post}_runtime_resume may not be called in pairs. Take sr device as example, when sr device goes to runtime suspend, blk_{pre|post}_runtime_suspend will be called since sr device defined pm->runtime_suspend. But blk_{pre|post}_runtime_resume will not be called since sr device doesn't have pm->runtime_resume. so, sr device can not resume correctly anymore. More discussion can be found from below link. http://marc.info/?l=linux-scsi&m=144163730531875&w=2 Signed-off-by: Ken Xue Acked-by: Alan Stern Cc: Xiangliang Yu Cc: James E.J. Bottomley Cc: Jens Axboe Cc: Michael Terry Cc: stable@vger.kernel.org Signed-off-by: Martin K. Petersen --- drivers/scsi/scsi_pm.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c index e4b799837948..459abe1dcc87 100644 --- a/drivers/scsi/scsi_pm.c +++ b/drivers/scsi/scsi_pm.c @@ -219,13 +219,13 @@ static int sdev_runtime_suspend(struct device *dev) struct scsi_device *sdev = to_scsi_device(dev); int err = 0; - if (pm && pm->runtime_suspend) { - err = blk_pre_runtime_suspend(sdev->request_queue); - if (err) - return err; + err = blk_pre_runtime_suspend(sdev->request_queue); + if (err) + return err; + if (pm && pm->runtime_suspend) err = pm->runtime_suspend(dev); - blk_post_runtime_suspend(sdev->request_queue, err); - } + blk_post_runtime_suspend(sdev->request_queue, err); + return err; } @@ -248,11 +248,11 @@ static int sdev_runtime_resume(struct device *dev) const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL; int err = 0; - if (pm && pm->runtime_resume) { - blk_pre_runtime_resume(sdev->request_queue); + blk_pre_runtime_resume(sdev->request_queue); + if (pm && pm->runtime_resume) err = pm->runtime_resume(dev); - blk_post_runtime_resume(sdev->request_queue, err); - } + blk_post_runtime_resume(sdev->request_queue, err); + return err; } -- cgit v1.2.3 From 5e1033561da1152c57b97ee84371dba2b3d64c25 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Fri, 11 Dec 2015 09:16:38 -0800 Subject: ses: fix additional element traversal bug KASAN found that our additional element processing scripts drop off the end of the VPD page into unallocated space. The reason is that not every element has additional information but our traversal routines think they do, leading to them expecting far more additional information than is present. Fix this by adding a gate to the traversal routine so that it only processes elements that are expected to have additional information (list is in SES-2 section 6.1.13.1: Additional Element Status diagnostic page overview) Reported-by: Pavel Tikhomirov Tested-by: Pavel Tikhomirov Cc: stable@vger.kernel.org Signed-off-by: James Bottomley --- drivers/scsi/ses.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c index 7d9cec50b77d..044d06410d4c 100644 --- a/drivers/scsi/ses.c +++ b/drivers/scsi/ses.c @@ -559,7 +559,15 @@ static void ses_enclosure_data_process(struct enclosure_device *edev, if (desc_ptr) desc_ptr += len; - if (addl_desc_ptr) + if (addl_desc_ptr && + /* only find additional descriptions for specific devices */ + (type_ptr[0] == ENCLOSURE_COMPONENT_DEVICE || + type_ptr[0] == ENCLOSURE_COMPONENT_ARRAY_DEVICE || + type_ptr[0] == ENCLOSURE_COMPONENT_SAS_EXPANDER || + /* these elements are optional */ + type_ptr[0] == ENCLOSURE_COMPONENT_SCSI_TARGET_PORT || + type_ptr[0] == ENCLOSURE_COMPONENT_SCSI_INITIATOR_PORT || + type_ptr[0] == ENCLOSURE_COMPONENT_CONTROLLER_ELECTRONICS)) addl_desc_ptr += addl_desc_ptr[1] + 2; } -- cgit v1.2.3 From 3b91d09c1ca69a69c470efe5fbf346e3e90181d5 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Wed, 9 Dec 2015 11:12:03 -0800 Subject: scsi_transport_sas: add is_sas_attached() function Adds a function designed to be callable any time (regardless of whether the transport attributes are configured or not) which returns true if the device is attached over a SAS transport. The design of this function is that transport specific functions can be embedded within a if (is_sas_attached(sdev)) { ... } which would be compiled out (and thus eliminate the symbols) if SAS is not configured. Reviewed-by: Hannes Reinecke Signed-off-by: James Bottomley --- drivers/scsi/scsi_transport_sas.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index 30d26e345dcc..b17f763a73b2 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -340,6 +340,22 @@ static int do_sas_phy_delete(struct device *dev, void *data) return 0; } +/** + * is_sas_attached - check if device is SAS attached + * @sdev: scsi device to check + * + * returns true if the device is SAS attached + */ +int is_sas_attached(struct scsi_device *sdev) +{ + struct Scsi_Host *shost = sdev->host; + + return shost->transportt->host_attrs.ac.class == + &sas_host_class.class; +} +EXPORT_SYMBOL(is_sas_attached); + + /** * sas_remove_children - tear down a devices SAS data structures * @dev: device belonging to the sas object -- cgit v1.2.3 From bcf508c13385e74972f5cc06d8471d5c100395b0 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Wed, 9 Dec 2015 11:13:35 -0800 Subject: scsi_transport_sas: add function to get SAS endpoint address For a device known to be SAS connected, this will return the endpoint address. This is useful for getting the SAS address of SATA devices. Reviewed-by: Hannes Reinecke Signed-off-by: James Bottomley --- drivers/scsi/scsi_transport_sas.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index b17f763a73b2..80520e2f0fa2 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -382,6 +382,20 @@ void sas_remove_host(struct Scsi_Host *shost) } EXPORT_SYMBOL(sas_remove_host); +/** + * sas_get_address - return the SAS address of the device + * @sdev: scsi device + * + * Returns the SAS address of the scsi device + */ +u64 sas_get_address(struct scsi_device *sdev) +{ + struct sas_end_device *rdev = sas_sdev_to_rdev(sdev); + + return rdev->rphy.identify.sas_address; +} +EXPORT_SYMBOL(sas_get_address); + /** * sas_tlr_supported - checking TLR bit in vpd 0x90 * @sdev: scsi device struct -- cgit v1.2.3 From 3f8d6f2a0797e8c650a47e5c1b5c2601a46f4293 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Wed, 9 Dec 2015 12:56:07 -0800 Subject: ses: fix discovery of SATA devices in SAS enclosures The current discovery routines use the VPD 0x83 inquiry page to find the device SAS address and match it to the end point in the enclosure. This doesn't work for SATA devices because expanders (or hosts) simply make up an endpoint address for STP and thus the address returned by the VPD page never matches. Instead of doing this, for SAS attached devices, match by the direct endpoint address instead. Signed-off-by: James Bottomley --- drivers/scsi/Kconfig | 1 + drivers/scsi/ses.c | 22 ++++------------------ 2 files changed, 5 insertions(+), 18 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 64eed87d34a8..90cd7cd6d130 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -194,6 +194,7 @@ config CHR_DEV_SCH config SCSI_ENCLOSURE tristate "SCSI Enclosure Support" depends on SCSI && ENCLOSURE_SERVICES + depends on m || SCSI_SAS_ATTRS != m help Enclosures are devices sitting on or in SCSI backplanes that manage devices. If you have a disk cage, the chances are that diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c index 044d06410d4c..53ef1cb6418e 100644 --- a/drivers/scsi/ses.c +++ b/drivers/scsi/ses.c @@ -34,6 +34,8 @@ #include #include +#include + struct ses_device { unsigned char *page1; unsigned char *page1_types; @@ -579,31 +581,15 @@ static void ses_enclosure_data_process(struct enclosure_device *edev, static void ses_match_to_enclosure(struct enclosure_device *edev, struct scsi_device *sdev) { - unsigned char *desc; struct efd efd = { .addr = 0, }; ses_enclosure_data_process(edev, to_scsi_device(edev->edev.parent), 0); - if (!sdev->vpd_pg83_len) - return; - - desc = sdev->vpd_pg83 + 4; - while (desc < sdev->vpd_pg83 + sdev->vpd_pg83_len) { - enum scsi_protocol proto = desc[0] >> 4; - u8 code_set = desc[0] & 0x0f; - u8 piv = desc[1] & 0x80; - u8 assoc = (desc[1] & 0x30) >> 4; - u8 type = desc[1] & 0x0f; - u8 len = desc[3]; - - if (piv && code_set == 1 && assoc == 1 - && proto == SCSI_PROTOCOL_SAS && type == 3 && len == 8) - efd.addr = get_unaligned_be64(&desc[4]); + if (is_sas_attached(sdev)) + efd.addr = sas_get_address(sdev); - desc += len + 4; - } if (efd.addr) { efd.dev = &sdev->sdev_gendev; -- cgit v1.2.3