1. 21 6月, 2013 27 次提交
  2. 05 6月, 2013 3 次提交
    • M
      IB/qib: Fix lockdep splat in qib_alloc_lkey() · f3bdf344
      Mike Marciniszyn 提交于
      The following backtrace is reported with CONFIG_PROVE_RCU:
      
          drivers/infiniband/hw/qib/qib_keys.c:64 suspicious rcu_dereference_check() usage!
          other info that might help us debug this:
          rcu_scheduler_active = 1, debug_locks = 1
          4 locks held by kworker/0:1/56:
          #0:  (events){.+.+.+}, at: [<ffffffff8107a4f5>] process_one_work+0x165/0x4a0
          #1:  ((&wfc.work)){+.+.+.}, at: [<ffffffff8107a4f5>] process_one_work+0x165/0x4a0
          #2:  (device_mutex){+.+.+.}, at: [<ffffffffa0148dd8>] ib_register_device+0x38/0x220 [ib_core]
          #3:  (&(&dev->lk_table.lock)->rlock){......}, at: [<ffffffffa017e81c>] qib_alloc_lkey+0x3c/0x1b0 [ib_qib]
      
          stack backtrace:
          Pid: 56, comm: kworker/0:1 Not tainted 3.10.0-rc1+ #6
          Call Trace:
          [<ffffffff810c0b85>] lockdep_rcu_suspicious+0xe5/0x130
          [<ffffffffa017e8e1>] qib_alloc_lkey+0x101/0x1b0 [ib_qib]
          [<ffffffffa0184886>] qib_get_dma_mr+0xa6/0xd0 [ib_qib]
          [<ffffffffa01461aa>] ib_get_dma_mr+0x1a/0x50 [ib_core]
          [<ffffffffa01678dc>] ib_mad_port_open+0x12c/0x390 [ib_mad]
          [<ffffffff810c2c55>] ?  trace_hardirqs_on_caller+0x105/0x190
          [<ffffffffa0167b92>] ib_mad_init_device+0x52/0x110 [ib_mad]
          [<ffffffffa01917c0>] ?  sl2vl_attr_show+0x30/0x30 [ib_qib]
          [<ffffffffa0148f49>] ib_register_device+0x1a9/0x220 [ib_core]
          [<ffffffffa01b1685>] qib_register_ib_device+0x735/0xa40 [ib_qib]
          [<ffffffff8106ba98>] ? mod_timer+0x118/0x220
          [<ffffffffa017d425>] qib_init_one+0x1e5/0x400 [ib_qib]
          [<ffffffff812ce86e>] local_pci_probe+0x4e/0x90
          [<ffffffff81078118>] work_for_cpu_fn+0x18/0x30
          [<ffffffff8107a566>] process_one_work+0x1d6/0x4a0
          [<ffffffff8107a4f5>] ?  process_one_work+0x165/0x4a0
          [<ffffffff8107c9c9>] worker_thread+0x119/0x370
          [<ffffffff8107c8b0>] ?  manage_workers+0x180/0x180
          [<ffffffff8108294e>] kthread+0xee/0x100
          [<ffffffff81082860>] ?  __init_kthread_worker+0x70/0x70
          [<ffffffff815c04ac>] ret_from_fork+0x7c/0xb0
          [<ffffffff81082860>] ?  __init_kthread_worker+0x70/0x70
      
      Per Documentation/RCU/lockdep-splat.txt, the code now uses rcu_access_pointer()
      vs. rcu_dereference().
      Reported-by: NJay Fenlason <fenlason@redhat.com>
      Reviewed-by: NDean Luick <dean.luick@intel.com>
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      f3bdf344
    • O
      IB/iser: Add Mellanox copyright · 28f292e8
      Or Gerlitz 提交于
      Add Mellanox copyright to the iser initiator source code which I maintain.
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      28f292e8
    • R
      IB/iser: Fix device removal flow · 5b61ff43
      Roi Dayan 提交于
      Change the code to destroy the "last opened" rdma_cm id after making
      sure we released all other objects (QP, CQs, PD, etc) associated with
      the IB device.
      
      Since iser accesses the IB device using the rdma_cm id, we need to
      free any objects that are related to the device that is associated
      with the rdma_cm id prior to destroying that id.  When this isn't
      done, the low level driver that created this device can be unloaded
      before iser has a chance to free all the objects and a such a call may
      invoke code segment which isn't valid any more and crash.
      
      Cc: Sean Hefty <sean.hefty@intel.com
      Signed-off-by: NRoi Dayan <roid@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      5b61ff43
  3. 30 5月, 2013 1 次提交
    • N
      ib_srpt: Call target_sess_cmd_list_set_waiting during shutdown_session · 1d19f780
      Nicholas Bellinger 提交于
      Given that srpt_release_channel_work() calls target_wait_for_sess_cmds()
      to allow outstanding se_cmd_t->cmd_kref a change to complete, the call
      to perform target_sess_cmd_list_set_waiting() needs to happen in
      srpt_shutdown_session()
      
      Also, this patch adds an explicit call to srpt_shutdown_session() within
      srpt_drain_channel() so that target_sess_cmd_list_set_waiting() will be
      called in the cases where TFO->shutdown_session() is not triggered
      directly by TCM.
      
      Cc: Joern Engel <joern@logfs.org>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      1d19f780
  4. 29 5月, 2013 1 次提交
  5. 21 5月, 2013 1 次提交
  6. 08 5月, 2013 2 次提交
  7. 02 5月, 2013 4 次提交
  8. 30 4月, 2013 1 次提交