1. 08 8月, 2017 1 次提交
    • B
      scsi: ipr: Fix scsi-mq lockdep issue · b0e17a9b
      Brian King 提交于
      Fixes the following lockdep warning that can occur when scsi-mq is
      enabled with ipr due to ipr calling scsi_unblock_requests from irq
      context. The fix is to move the call to scsi_unblock_requests to ipr's
      existing workqueue.
      
      stack backtrace:
      CPU: 28 PID: 0 Comm: swapper/28 Not tainted 4.13.0-rc2-gcc6x-gf74c89bd #1
      Call Trace:
      [c000001fffe97550] [c000000000b50818] dump_stack+0xe8/0x160 (unreliable)
      [c000001fffe97590] [c0000000001586d0] print_usage_bug+0x2d0/0x390
      [c000001fffe97640] [c000000000158f34] mark_lock+0x7a4/0x8e0
      [c000001fffe976f0] [c00000000015a000] __lock_acquire+0x6a0/0x1a70
      [c000001fffe97860] [c00000000015befc] lock_acquire+0xec/0x2e0
      [c000001fffe97930] [c000000000b71514] _raw_spin_lock+0x44/0x70
      [c000001fffe97960] [c0000000005b60f4] blk_mq_sched_dispatch_requests+0xa4/0x2a0
      [c000001fffe979c0] [c0000000005acac0] __blk_mq_run_hw_queue+0x100/0x2c0
      [c000001fffe97a00] [c0000000005ad478] __blk_mq_delay_run_hw_queue+0x118/0x130
      [c000001fffe97a40] [c0000000005ad61c] blk_mq_start_hw_queues+0x6c/0xa0
      [c000001fffe97a80] [c000000000797aac] scsi_kick_queue+0x2c/0x60
      [c000001fffe97aa0] [c000000000797cf0] scsi_run_queue+0x210/0x360
      [c000001fffe97b10] [c00000000079b888] scsi_run_host_queues+0x48/0x80
      [c000001fffe97b40] [c0000000007b6090] ipr_ioa_bringdown_done+0x70/0x1e0
      [c000001fffe97bc0] [c0000000007bc860] ipr_reset_ioa_job+0x80/0xf0
      [c000001fffe97bf0] [c0000000007b4d50] ipr_reset_timer_done+0xd0/0x100
      [c000001fffe97c30] [c0000000001937bc] call_timer_fn+0xdc/0x4b0
      [c000001fffe97cf0] [c000000000193d08] expire_timers+0x178/0x330
      [c000001fffe97d60] [c0000000001940c8] run_timer_softirq+0xb8/0x120
      [c000001fffe97de0] [c000000000b726a8] __do_softirq+0x168/0x6d8
      [c000001fffe97ef0] [c0000000000df2c8] irq_exit+0x108/0x150
      [c000001fffe97f10] [c000000000017bf4] __do_irq+0x2a4/0x4a0
      [c000001fffe97f90] [c00000000002da50] call_do_irq+0x14/0x24
      [c0000007fad93aa0] [c000000000017e8c] do_IRQ+0x9c/0x140
      [c0000007fad93af0] [c000000000008b98] hardware_interrupt_common+0x138/0x140
      Reported-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      b0e17a9b
  2. 24 3月, 2017 1 次提交
  3. 09 11月, 2016 1 次提交
  4. 19 9月, 2016 1 次提交
  5. 26 8月, 2016 1 次提交
  6. 27 7月, 2016 1 次提交
  7. 14 7月, 2016 1 次提交
  8. 12 12月, 2015 1 次提交
  9. 10 11月, 2015 4 次提交
  10. 31 7月, 2015 3 次提交
  11. 02 6月, 2015 1 次提交
  12. 10 4月, 2015 4 次提交
  13. 19 1月, 2015 1 次提交
    • B
      ipr: wait for aborted command responses · 6cdb0817
      Brian King 提交于
      Fixes a race condition in abort handling that was injected
      when multiple interrupt support was added. When only a single
      interrupt is present, the adapter guarantees it will send
      responses for aborted commands prior to the response for the
      abort command itself. With multiple interrupts, these responses
      generally come back on different interrupts, so we need to
      ensure the abort thread waits until the aborted command is
      complete so we don't perform a double completion. This race
      condition was being hit frequently in environments which
      were triggering command timeouts, which was resulting in
      a double completion causing a kernel oops.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Reviewed-by: NWendy Xiong <wenxiong@linux.vnet.ibm.com>
      Tested-by: NWendy Xiong <wenxiong@linux.vnet.ibm.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      6cdb0817
  14. 15 12月, 2014 1 次提交
  15. 12 11月, 2014 1 次提交
  16. 26 9月, 2014 1 次提交
  17. 25 9月, 2014 1 次提交
  18. 20 3月, 2014 5 次提交
  19. 20 12月, 2013 1 次提交
  20. 19 12月, 2013 1 次提交
  21. 26 8月, 2013 1 次提交
  22. 05 6月, 2013 1 次提交
  23. 13 5月, 2013 1 次提交
  24. 03 5月, 2013 1 次提交
  25. 24 2月, 2013 1 次提交
  26. 30 1月, 2013 3 次提交