1. 01 Dec, 2018 1 commit
  2. 09 Aug, 2018 1 commit
  3. 14 Jun, 2017 1 commit
  4. 26 Jan, 2017 1 commit
    • Quinn Tran's avatar
      qla2xxx: Fix crash due to null pointer access · 7ea1eb73
      Quinn Tran authored
      commit fc1ffd6c
      
       upstream.
      
      During code inspection, while investigating following stack trace
      seen on one of the test setup, we found out there was possibility
      of memory leak becuase driver was not unwinding the stack properly.
      
      This issue has not been reproduced in a test environment or on a
      customer setup.
      
      Here's stack trace that was seen.
      
      [1469877.797315] Call Trace:
      [1469877.799940]  [<ffffffffa03ab6e9>] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
      [1469877.806980]  [<ffffffffa03ac50a>] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
      [1469877.814013]  [<ffffffff813b6d01>] ? __pm_runtime_resume+0x51/0xa0
      [1469877.820265]  [<ffffffff8157c1f5>] ? _raw_spin_lock_irqsave+0x25/0x90
      [1469877.826776]  [<ffffffff8157cd2d>] ? _raw_spin_unlock_irqrestore+0x6d/0x80
      [1469877.833720]  [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100
      [1469877.839885]  [<ffffffff8157cd0c>] ? _raw_spin_unlock_irqrestore+0x4c/0x80
      [1469877.846830]  [<ffffffff81319b9c>] local_pci_probe+0x4c/0xb0
      [1469877.852562]  [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100
      [1469877.858727]  [<ffffffff81319c89>] pci_call_probe+0x89/0xb0
      Signed-off-by: default avatarQuinn Tran <quinn.tran@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      [ bvanassche: Fixed spelling in patch description ]
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ea1eb73
  5. 18 Nov, 2016 1 commit
    • Bill Kuzeja's avatar
      scsi: qla2xxx: Fix scsi scan hang triggered if adapter fails during init · 6e897d03
      Bill Kuzeja authored
      commit a5dd506e upstream.
      
      A system can get hung task timeouts if a qlogic board fails during
      initialization (if the board breaks again or fails the init). The hang
      involves the scsi scan.
      
      In a nutshell, since commit beb9e315 ("qla2xxx: Prevent removal and
      board_disable race"):
      
      ...it is possible to have freed ha (base_vha->hw) early by a call to
      qla2x00_remove_one when pdev->enable_cnt equals zero:
      
             if (!atomic_read(&pdev->enable_cnt)) {
                     scsi_host_put(base_vha->host);
                     kfree(ha);
                     pci_set_drvdata(pdev, NULL);
                     return;
      
      Almost always, the scsi_host_put above frees the vha structure
      (attached to the end of the Scsi_Host we're putting) since it's the last
      put, and life is good.  However, if we are entering this routine because
      the adapter has broken sometime during initialization AND a scsi scan is
      already in progress (and has done its own scsi_host_get), vha will not
      be freed. What's worse, the scsi scan will access the freed ha structure
      through qla2xxx_scan_finished:
      
              if (time > vha->hw->loop_reset_delay * HZ)
                      return 1;
      
      The scsi scan keeps checking to see if a scan is complete by calling
      qla2xxx_scan_finished. There is a timeout value that limits the length
      of time a scan can take (hw->loop_reset_delay, usually set to 5
      seconds), but this definition is in the data structure (hw) that can get
      freed early.
      
      This can yield unpredictable results, the worst of which is that the
      scsi scan can hang indefinitely. This happens when the freed structure
      gets reused and loop_reset_delay gets overwritten with garbage, which
      the scan obliviously uses as its timeout value.
      
      The fix for this is simple: at the top of qla2xxx_scan_finished, check
      for the UNLOADING bit in the vha structure (_vha is not freed at this
      point).  If UNLOADING is set, we exit the scan for this adapter
      immediately. After this last reference to the ha structure, we'll exit
      the scan for this adapter, and continue on.
      
      This problem is hard to hit, but I have run into it doing negative
      testing many times now (with a test specifically designed to bring it
      out), so I can verify that this fix works. My testing has been against a
      RHEL7 driver variant, but the bug and patch are equally relevant to to
      the upstream driver.
      
      Fixes: beb9e315
      
       ("qla2xxx: Prevent removal and board_disable race")
      Signed-off-by: default avatarBill Kuzeja <william.kuzeja@stratus.com>
      Acked-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e897d03
  6. 03 Mar, 2016 1 commit
    • Quinn Tran's avatar
      qla2xxx: Fix stale pointer access. · 921d439c
      Quinn Tran authored
      commit cb43285f upstream.
      
      [ Upstream Commit 84e32a06 ]
      
      Commit 84e32a06
      
       ("qla2xxx: Use pci_enable_msix_range() instead of
      pci_enable_msix()") introduced a regression when target mode is enabled.
      In qla24xx_enable_msix(), ha->max_rsp_queues was incorrectly set
      to a value higher than the number of response queues allocated causing
      an invalid dereference. Specifically here in qla2x00_init_rings():
          *rsp->in_ptr = 0;
      
      Add additional check to make sure the pointer is valid. following
      call stack will be seen
      
      ---- 8< ----
      RIP: 0010:[<ffffffffa02ccadc>]  [<ffffffffa02ccadc>] qla2x00_init_rings+0xdc/0x320 [qla2xxx]
      RSP: 0018:ffff880429447dd8  EFLAGS: 00010082
      ....
      Call Trace:
      [<ffffffffa02ceb40>] qla2x00_abort_isp+0x170/0x6b0 [qla2xxx]
      [<ffffffffa02c6f77>] qla2x00_do_dpc+0x357/0x7f0 [qla2xxx]
      [<ffffffffa02c6c20>] ? qla2x00_relogin+0x260/0x260 [qla2xxx]
      [<ffffffff8107d2c9>] kthread+0xc9/0xe0
      [<ffffffff8107d200>] ? flush_kthread_worker+0x90/0x90
      [<ffffffff8172cc6f>] ret_from_fork+0x3f/0x70
      [<ffffffff8107d200>] ? flush_kthread_worker+0x90/0x90
      ---- 8< ----
      Signed-off-by: default avatarQuinn Tran <quinn.tran@qlogic.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      921d439c
  7. 10 Nov, 2015 1 commit
  8. 27 Aug, 2015 6 commits
  9. 26 Aug, 2015 1 commit
  10. 24 Jul, 2015 4 commits
  11. 13 Jun, 2015 1 commit
  12. 10 Apr, 2015 1 commit
  13. 06 Mar, 2015 2 commits
  14. 05 Jan, 2015 1 commit
    • Bruno Prémont's avatar
      qla2xxx: fix busy wait regression · 975f7d46
      Bruno Prémont authored
      Commit e05fe292
      
       (qla2xxx: Honor FCP_RSP retry delay timer field.)
      causes systems to busy-wait for about 3 minutes after boot prior to
      detecting SAN disks.
      
      During this wait period one kworker is running full-time
      (though /proc/<pid>/stack has no useful data). Another kworker is
      waiting for IO to complete during that whole time period.
      
      Looking at drivers/scsi/qla2xxx/qla_os.c, fcport->retry_delay_timestamp
      has a special value of 0 though that 0 value forces system to wait when
      jiffies is very large value (e.g. 4294952605 - "negative" value when
      signed on 32bit systems).
      Signed-off-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Acked-by: default avatarChad Dupuis <chad.dupuis@qlogic.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      975f7d46
  15. 04 Dec, 2014 1 commit
  16. 24 Nov, 2014 2 commits
  17. 12 Nov, 2014 4 commits
  18. 25 Sep, 2014 10 commits