1. 26 11月, 2015 3 次提交
  2. 21 11月, 2015 2 次提交
    • A
      scsi: hpsa: select CONFIG_SCSI_SAS_ATTR · 653cfb85
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Fixes: d04e62b9 ("hpsa: add in sas transport class")
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NDon Brace <don.brace@pmcs.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      653cfb85
    • A
      scsi: advansys needs ISA dma api for ISA support · 2b8bbdb9
      Arnd Bergmann 提交于
      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
      6571fb3f ("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: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      2b8bbdb9
  3. 20 11月, 2015 3 次提交
    • V
      scsi_sysfs: protect against double execution of __scsi_remove_device() · be821fd8
      Vitaly Kuznetsov 提交于
      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:[<ffffffff81169979>]  [<ffffffff81169979>] bdi_destroy+0x39/0x220
       ...
       [<ffffffff814aecdc>] ? _raw_spin_unlock_irq+0x2c/0x40
       [<ffffffff8127b7db>] blk_cleanup_queue+0x17b/0x270
       [<ffffffffa00b54c4>] __scsi_remove_device+0x54/0xd0 [scsi_mod]
       [<ffffffffa00b556b>] scsi_remove_device+0x2b/0x40 [scsi_mod]
       [<ffffffffa00ec47d>] storvsc_remove_lun+0x3d/0x60 [hv_storvsc]
       [<ffffffff81080791>] 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: NVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      be821fd8
    • M
      st: fix potential null pointer dereference. · ab08ee14
      Maurizio Lombardi 提交于
      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: NMaurizio Lombardi <mlombard@redhat.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: NTomas Henzl <thenzl@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      ab08ee14
    • V
      scsi: report 'INQUIRY result too short' once per host · a35bb445
      Vitaly Kuznetsov 提交于
      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: NVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      a35bb445
  4. 18 11月, 2015 2 次提交
    • A
      advansys: fix big-endian builds · 757b22f9
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Fixes: 811ddc05 ("advansys: use DMA-API for mapping sense buffer")
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Cc: stable@vger.kernel.org # v4.2+
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      757b22f9
    • B
      qla2xxx: Fix rwlock recursion · 0874f8ec
      Bart Van Assche 提交于
      This patch fixes the following kernel bug:
      
      kernel:BUG: rwlock recursion on CPU#2, insmod/39333, ffff8803e998cb28
      kernel: Call Trace:
      kernel: [<ffffffff812bce44>] dump_stack+0x48/0x64
      kernel: [<ffffffff810a8047>] rwlock_bug+0x67/0x70
      kernel: [<ffffffff810a833a>] do_raw_write_lock+0x8a/0xa0
      kernel: [<ffffffff815f3033>] _raw_write_lock_irqsave+0x63/0x80
      kernel: [<ffffffffa08087c8>] qla82xx_rd_32+0xe8/0x140 [qla2xxx]
      kernel: [<ffffffffa0808845>] qla82xx_crb_win_lock+0x25/0x60 [qla2xxx]
      kernel: [<ffffffffa0808976>] qla82xx_wr_32+0xf6/0x150 [qla2xxx]
      kernel: [<ffffffffa0808ac0>] qla82xx_disable_intrs+0x50/0x80 [qla2xxx]
      kernel: [<ffffffffa080630a>] qla82xx_reset_chip+0x1a/0x20 [qla2xxx]
      kernel: [<ffffffffa07d6ef2>] qla2x00_initialize_adapter+0x132/0x420 [qla2xxx]
      kernel: [<ffffffffa08087c8>] qla82xx_rd_32+0xe8/0x140 [qla2xxx]
      kernel: [<ffffffffa0808845>] qla82xx_crb_win_lock+0x25/0x60 [qla2xxx]
      kernel: [<ffffffffa0808976>] qla82xx_wr_32+0xf6/0x150 [qla2xxx]
      kernel: [<ffffffffa0808ac0>] qla82xx_disable_intrs+0x50/0x80 [qla2xxx]
      kernel: [<ffffffffa080630a>] qla82xx_reset_chip+0x1a/0x20 [qla2xxx]
      kernel: [<ffffffffa07d6ef2>] qla2x00_initialize_adapter+0x132/0x420 [qla2xxx]
      kernel: [<ffffffffa07c964e>] qla2x00_probe_one+0xefe/0x2130 [qla2xxx]
      kernel: [<ffffffff8130052c>] local_pci_probe+0x4c/0xa0
      kernel: [<ffffffff81300603>] pci_call_probe+0x83/0xa0
      kernel: [<ffffffff813008cf>] pci_device_probe+0x7f/0xb0
      kernel: [<ffffffff813e2e83>] really_probe+0x133/0x390
      kernel: [<ffffffff813e3139>] driver_probe_device+0x59/0xd0
      kernel: [<ffffffff813e3251>] __driver_attach+0xa1/0xb0
      kernel: [<ffffffff813e0cdd>] bus_for_each_dev+0x8d/0xb0
      kernel: [<ffffffff813e28ee>] driver_attach+0x1e/0x20
      kernel: [<ffffffff813e2252>] bus_add_driver+0x1d2/0x290
      kernel: [<ffffffff813e3970>] driver_register+0x60/0xe0
      kernel: [<ffffffff813009e4>] __pci_register_driver+0x64/0x70
      kernel: [<ffffffffa04bc1cb>] qla2x00_module_init+0x1cb/0x21b [qla2xxx]
      kernel: [<ffffffff8100027d>] do_one_initcall+0xad/0x1c0
      kernel: [<ffffffff810e2859>] do_init_module+0x69/0x210
      kernel: [<ffffffff810e4e5c>] load_module+0x5cc/0x750
      kernel: [<ffffffff810e5162>] SyS_init_module+0x92/0xc0
      kernel: [<ffffffff815f37d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
      
      Fixes: 8dfa4b5a ("qla2xxx: Fix sparse annotation")
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Reported-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
      Tested-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
      Reviewed-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
      Reviewed-by: NChad Dupuis <chad.dupuis@qlogic.com>
      Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
      Cc: Xose Vazquez Perez <xose.vazquez@gmail.com>
      Cc: stable <stable@vger.kernel.org> # v4.3+
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      0874f8ec
  5. 14 11月, 2015 3 次提交
  6. 12 11月, 2015 27 次提交