1. 26 Nov, 2015 1 commit
  2. 20 Nov, 2015 2 commits
    • Arnd Bergmann's avatar
      scsi: hpsa: select CONFIG_SCSI_SAS_ATTR · 653cfb85
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: d04e62b9 ("hpsa: add in sas transport class")
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarDon Brace <don.brace@pmcs.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      653cfb85
    • Arnd Bergmann's avatar
      scsi: advansys needs ISA dma api for ISA support · 2b8bbdb9
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      2b8bbdb9
  3. 19 Nov, 2015 3 commits
    • Vitaly Kuznetsov's avatar
      scsi_sysfs: protect against double execution of __scsi_remove_device() · be821fd8
      Vitaly Kuznetsov authored
      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: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      be821fd8
    • Maurizio Lombardi's avatar
      st: fix potential null pointer dereference. · ab08ee14
      Maurizio Lombardi authored
      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: default avatarMaurizio Lombardi <mlombard@redhat.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ab08ee14
    • Vitaly Kuznetsov's avatar
      scsi: report 'INQUIRY result too short' once per host · a35bb445
      Vitaly Kuznetsov authored
      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: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a35bb445
  4. 18 Nov, 2015 1 commit
    • Arnd Bergmann's avatar
      advansys: fix big-endian builds · 757b22f9
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 811ddc05 ("advansys: use DMA-API for mapping sense buffer")
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Cc: stable@vger.kernel.org # v4.2+
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      757b22f9
  5. 17 Nov, 2015 1 commit
    • Bart Van Assche's avatar
      qla2xxx: Fix rwlock recursion · 0874f8ec
      Bart Van Assche authored
      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: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reported-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Tested-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Reviewed-by: default avatarChad 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: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      0874f8ec
  6. 13 Nov, 2015 3 commits
  7. 12 Nov, 2015 14 commits
  8. 11 Nov, 2015 14 commits
  9. 10 Nov, 2015 1 commit
    • Benjamin Rood's avatar
      pm80xx: remove the SCSI host before detaching from SAS transport · 2a188cb4
      Benjamin Rood authored
      Previously, when this module was unloaded via 'rmmod' with at least one
      drive attached, the SCSI error handler thread would become stuck in an
      infinite recovery loop and lockup the system, necessitating a reboot.
      
      Once the SAS layer is detached, the driver will fail any subsequent
      commands since the target devices are removed.  However, removing the
      SCSI host generates a SYNCHRONIZE CACHE (10) command, which was failed
      and left the error handler no method of recovery.
      
      This patch simply removes the SCSI host first so that no more commands
      can come down, prior to cleaning up the SAS layer.  Note that the stack
      is built up with the SCSI host first, and then the SAS layer.  Perhaps
      it should be reversed for symmetry, so that commands cannot be sent to
      the pm80xx driver prior to attaching the SAS layer?
      
      What was really strange about this bug was that it was introduced at
      commit cff549e4 ("[SCSI]: proper state checking and module refcount
      handling in scsi_device_get").  This commit appears to tinker with how
      the reference counting is performed for SCSI device objects.  My theory
      is that prior to this commit, the refcount for a device object was
      blindly incremented at some point during the teardown process which
      coincidentially made the device stick around during the procedure, which
      also coincidentially made any commands sent to the driver not fail
      (since the device was technically still "there").  After this commit was
      applied, my theory is the refcount for the device object is not being
      incremented at a specific point anymore, which makes the device go away,
      and thus made the pm80xx driver fail any subsequent commands.
      
      You may also want to see the following for more details:
      
      [1] http://www.spinics.net/lists/linux-scsi/msg37208.html
      [2] http://marc.info/?l=linux-scsi&m=144416476406993&w=2Signed-off-by: default avatarBenjamin Rood <brood@attotech.com>
      Acked-by: default avatarJack Wang <jinpu.wang@profitbricks.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      2a188cb4