1. 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
  2. 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
  3. 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
  4. 14 11月, 2015 3 次提交
  5. 12 11月, 2015 28 次提交
  6. 10 11月, 2015 2 次提交
    • B
      pm80xx: remove the SCSI host before detaching from SAS transport · 2a188cb4
      Benjamin Rood 提交于
      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: NBenjamin Rood <brood@attotech.com>
      Acked-by: NJack Wang <jinpu.wang@profitbricks.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      2a188cb4
    • J
      mvsas: remove SCSI host before detaching from SAS transport · 08d8a817
      Jack Wang 提交于
      commit cff549e4 ("scsi: proper state checking and module refcount
      handling in scsi_device_get") the reference count of scsi device was
      changed, which could lead to when rmmod with at least on drive attached,
      SCSI error handle will run into infinite loop, and lockup the system.
      
      Fix it by remove scsi host first, this way scsi core will not send
      commands down after detaching SAS transport.
      
      This is a follow up fix for Benjamin's fix for pm80xx.
      
      See also:
      http://www.spinics.net/lists/linux-scsi/msg90088.htmlSigned-off-by: NJack Wang <jinpu.wang@profitbricks.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      08d8a817
反馈
建议
客服 返回
顶部