linux-stable.git/drivers/infiniband/core, branch v3.5

RDMA/cma: QP type check on received REQs should be AND not OR

2012-06-20T03:04:04+00:00

Change || check to the intended && when checking the QP type in a
received connection request against the listening endpoint.

Signed-off-by: Sean Hefty 
Signed-off-by: Roland Dreier

Merge tag 'rdma-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband

2012-05-22T00:54:55+00:00

Pull InfiniBand/RDMA changes from Roland Dreier:
 - Add ocrdma hardware driver for Emulex IB-over-Ethernet adapters
 - Add generic and mlx4 support for "raw" QPs: allow suitably privileged
   applications to send and receive arbitrary packets directly to/from
   the hardware
 - Add "doorbell drop" handling to the cxgb4 driver
 - A fairly large batch of qib hardware driver changes
 - A few fixes for lockdep-detected issues
 - A few other miscellaneous fixes and cleanups

Fix up trivial conflict in drivers/net/ethernet/emulex/benet/be.h.

* tag 'rdma-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband: (53 commits)
  RDMA/cxgb4: Include vmalloc.h for vmalloc and vfree
  IB/mlx4: Fix mlx4_ib_add() error flow
  IB/core: Fix IB_SA_COMP_MASK macro
  IB/iser: Fix error flow in iser ep connection establishment
  IB/mlx4: Increase the number of vectors (EQs) available for ULPs
  RDMA/cxgb4: Add query_qp support
  RDMA/cxgb4: Remove kfifo usage
  RDMA/cxgb4: Use vmalloc() for debugfs QP dump
  RDMA/cxgb4: DB Drop Recovery for RDMA and LLD queues
  RDMA/cxgb4: Disable interrupts in c4iw_ev_dispatch()
  RDMA/cxgb4: Add DB Overflow Avoidance
  RDMA/cxgb4: Add debugfs RDMA memory stats
  cxgb4: DB Drop Recovery for RDMA and LLD queues
  cxgb4: Common platform specific changes for DB Drop Recovery
  cxgb4: Detect DB FULL events and notify RDMA ULD
  RDMA/cxgb4: Drop peer_abort when no endpoint found
  RDMA/cxgb4: Always wake up waiters in c4iw_peer_abort_intr()
  mlx4_core: Change bitmap allocator to work in round-robin fashion
  RDMA/nes: Don't call event handler if pointer is NULL
  RDMA/nes: Fix for the ORD value of the connecting peer
  ...

Merge branches 'core', 'cxgb4', 'ipath', 'iser', 'lockdep', 'mlx4', 'nes', 'ocrdma', 'qib' and 'raw-qp' into for-linus

2012-05-21T16:00:47+00:00

IB/core: Fix mismatch between locked and pinned pages

2012-05-11T18:38:22+00:00

Commit bc3e53f682d9 ("mm: distinguish between mlocked and pinned
pages") introduced a separate counter for pinned pages and used it in
the IB stack.  However, in ib_umem_get() the pinned counter is
incremented, but ib_umem_release() wrongly decrements the locked
counter.  Fix this.

Signed-off-by: Yishai Hadas 
Reviewed-by: Christoph Lameter 
Cc: 
Signed-off-by: Roland Dreier

IB/core: Add raw packet QP type

2012-05-08T18:18:09+00:00

IB_QPT_RAW_PACKET allows applications to build a complete packet,
including L2 headers, when sending; on the receive side, the HW will
not strip any headers.

This QP type is designed for userspace direct access to Ethernet; for
example by applications that do TCP/IP themselves.  Only processes
with the NET_RAW capability are allowed to create raw packet QPs (the
name "raw packet QP" is supposed to suggest an analogy to AF_PACKET /
SOL_RAW sockets).

Signed-off-by: Or Gerlitz 
Reviewed-by: Sean Hefty 
Signed-off-by: Roland Dreier

RDMA/cma: Fix lockdep false positive recursive locking

2012-05-08T18:17:34+00:00

The following lockdep problem was reported by Or Gerlitz :

    [ INFO: possible recursive locking detected ]
    3.3.0-32035-g1b2649e-dirty #4 Not tainted
    ---------------------------------------------
    kworker/5:1/418 is trying to acquire lock:
     (&id_priv->handler_mutex){+.+.+.}, at: [] rdma_destroy_i    d+0x33/0x1f0 [rdma_cm]

    but task is already holding lock:
     (&id_priv->handler_mutex){+.+.+.}, at: [] cma_disable_ca    llback+0x24/0x45 [rdma_cm]

    other info that might help us debug this:
     Possible unsafe locking scenario:

           CPU0
           ----
      lock(&id_priv->handler_mutex);
      lock(&id_priv->handler_mutex);

     *** DEADLOCK ***

     May be due to missing lock nesting notation

    3 locks held by kworker/5:1/418:
     #0:  (ib_cm){.+.+.+}, at: [] process_one_work+0x210/0x4a    6
     #1:  ((&(&work->work)->work)){+.+.+.}, at: [] process_on    e_work+0x210/0x4a6
     #2:  (&id_priv->handler_mutex){+.+.+.}, at: [] cma_disab    le_callback+0x24/0x45 [rdma_cm]

    stack backtrace:
    Pid: 418, comm: kworker/5:1 Not tainted 3.3.0-32035-g1b2649e-dirty #4
    Call Trace:
     [] ? console_unlock+0x1f4/0x204
     [] __lock_acquire+0x16b5/0x174e
     [] ? save_trace+0x3f/0xb3
     [] lock_acquire+0xf0/0x116
     [] ? rdma_destroy_id+0x33/0x1f0 [rdma_cm]
     [] mutex_lock_nested+0x64/0x2ce
     [] ? rdma_destroy_id+0x33/0x1f0 [rdma_cm]
     [] ? trace_hardirqs_on_caller+0x11e/0x155
     [] ? trace_hardirqs_on+0xd/0xf
     [] rdma_destroy_id+0x33/0x1f0 [rdma_cm]
     [] cma_req_handler+0x418/0x644 [rdma_cm]
     [] cm_process_work+0x32/0x119 [ib_cm]
     [] cm_req_handler+0x928/0x982 [ib_cm]
     [] ? cm_req_handler+0x982/0x982 [ib_cm]
     [] cm_work_handler+0x33/0xfe5 [ib_cm]
     [] ? trace_hardirqs_on_caller+0x11e/0x155
     [] ? cm_req_handler+0x982/0x982 [ib_cm]
     [] process_one_work+0x2bd/0x4a6
     [] ? process_one_work+0x210/0x4a6
     [] ? _raw_spin_unlock_irq+0x2b/0x40
     [] worker_thread+0x1d6/0x350
     [] ? rescuer_thread+0x241/0x241
     [] kthread+0x84/0x8c
     [] kernel_thread_helper+0x4/0x10
     [] ? retint_restore_args+0xe/0xe
     [] ? __init_kthread_worker+0x56/0x56
     [] ? gs_change+0xb/0xb

The actual locking is fine, since we're dealing with different locks,
but from the same lock class.  cma_disable_callback() acquires the
listening id mutex, whereas rdma_destroy_id() acquires the mutex for
the new connection id.  To fix this, delay the call to
rdma_destroy_id() until we've released the listening id mutex.

Signed-off-by: Sean Hefty 
Signed-off-by: Roland Dreier

IB/uverbs: Lock SRQ / CQ / PD objects in a consistent order

2012-05-08T18:17:34+00:00

Since XRC support was added, the uverbs code has locked SRQ, CQ and PD
objects needed during QP and SRQ creation in different orders
depending on the the code path.  This leads to the (at least
theoretical) possibility of deadlock, and triggers the lockdep splat
below.

Fix this by making sure we always lock the SRQ first, then CQs and
finally the PD.

    ======================================================
    [ INFO: possible circular locking dependency detected ]
    3.4.0-rc5+ #34 Not tainted
    -------------------------------------------------------
    ibv_srq_pingpon/2484 is trying to acquire lock:
     (SRQ-uobj){+++++.}, at: [] idr_read_uobj+0x2f/0x4d [ib_uverbs]

    but task is already holding lock:
     (CQ-uobj){+++++.}, at: [] idr_read_uobj+0x2f/0x4d [ib_uverbs]

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #2 (CQ-uobj){+++++.}:
           [] lock_acquire+0xbf/0xfe
           [] down_read+0x34/0x43
           [] idr_read_uobj+0x2f/0x4d [ib_uverbs]
           [] idr_read_obj+0x9/0x19 [ib_uverbs]
           [] ib_uverbs_create_qp+0x180/0x684 [ib_uverbs]
           [] ib_uverbs_write+0xb7/0xc2 [ib_uverbs]
           [] vfs_write+0xa7/0xee
           [] sys_write+0x45/0x69
           [] system_call_fastpath+0x16/0x1b

    -> #1 (PD-uobj){++++++}:
           [] lock_acquire+0xbf/0xfe
           [] down_read+0x34/0x43
           [] idr_read_uobj+0x2f/0x4d [ib_uverbs]
           [] idr_read_obj+0x9/0x19 [ib_uverbs]
           [] __uverbs_create_xsrq+0x96/0x386 [ib_uverbs]
           [] ib_uverbs_detach_mcast+0x1cd/0x1e6 [ib_uverbs]
           [] ib_uverbs_write+0xb7/0xc2 [ib_uverbs]
           [] vfs_write+0xa7/0xee
           [] sys_write+0x45/0x69
           [] system_call_fastpath+0x16/0x1b

    -> #0 (SRQ-uobj){+++++.}:
           [] __lock_acquire+0xa29/0xd06
           [] lock_acquire+0xbf/0xfe
           [] down_read+0x34/0x43
           [] idr_read_uobj+0x2f/0x4d [ib_uverbs]
           [] idr_read_obj+0x9/0x19 [ib_uverbs]
           [] ib_uverbs_create_qp+0x1e5/0x684 [ib_uverbs]
           [] ib_uverbs_write+0xb7/0xc2 [ib_uverbs]
           [] vfs_write+0xa7/0xee
           [] sys_write+0x45/0x69
           [] system_call_fastpath+0x16/0x1b

    other info that might help us debug this:

    Chain exists of:
      SRQ-uobj --> PD-uobj --> CQ-uobj

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----
      lock(CQ-uobj);
                                   lock(PD-uobj);
                                   lock(CQ-uobj);
      lock(SRQ-uobj);

     *** DEADLOCK ***

    3 locks held by ibv_srq_pingpon/2484:
     #0:  (QP-uobj){+.+...}, at: [] ib_uverbs_create_qp+0xe9/0x684 [ib_uverbs]
     #1:  (PD-uobj){++++++}, at: [] idr_read_uobj+0x2f/0x4d [ib_uverbs]
     #2:  (CQ-uobj){+++++.}, at: [] idr_read_uobj+0x2f/0x4d [ib_uverbs]

    stack backtrace:
    Pid: 2484, comm: ibv_srq_pingpon Not tainted 3.4.0-rc5+ #34
    Call Trace:
     [] print_circular_bug+0x1f8/0x209
     [] __lock_acquire+0xa29/0xd06
     [] ? __idr_get_uobj+0x20/0x5e [ib_uverbs]
     [] ? idr_read_uobj+0x2f/0x4d [ib_uverbs]
     [] lock_acquire+0xbf/0xfe
     [] ? idr_read_uobj+0x2f/0x4d [ib_uverbs]
     [] ? lock_release+0x166/0x189
     [] down_read+0x34/0x43
     [] ? idr_read_uobj+0x2f/0x4d [ib_uverbs]
     [] idr_read_uobj+0x2f/0x4d [ib_uverbs]
     [] idr_read_obj+0x9/0x19 [ib_uverbs]
     [] ib_uverbs_create_qp+0x1e5/0x684 [ib_uverbs]
     [] ? lock_acquire+0xdb/0xfe
     [] ? lock_release_non_nested+0x94/0x213
     [] ? might_fault+0x40/0x90
     [] ? might_fault+0x40/0x90
     [] ib_uverbs_write+0xb7/0xc2 [ib_uverbs]
     [] vfs_write+0xa7/0xee
     [] ? fget_light+0x3b/0x99
     [] sys_write+0x45/0x69
     [] system_call_fastpath+0x16/0x1b

Reported-by: Or Gerlitz 
Signed-off-by: Roland Dreier

IB/uverbs: Make lockdep output more readable

2012-05-08T18:17:34+00:00

Add names for our lockdep classes, so instead of having to decipher
lockdep output with mysterious names:

    Chain exists of:
      key#14 --> key#11 --> key#13

lockdep will give us something nicer:

    Chain exists of:
      SRQ-uobj --> PD-uobj --> CQ-uobj

Signed-off-by: Roland Dreier

IB/core: Use qp->usecnt to track multicast attach/detach

2012-05-08T18:16:54+00:00

Just as we don't allow PDs, CQs, etc. to be destroyed if there are QPs
that are attached to them, don't let a QP be destroyed if there are
multicast group(s) attached to it.  Use the existing usecnt field of
struct ib_qp which was added by commit 0e0ec7e ("RDMA/core: Export
ib_open_qp() to share XRC TGT QPs") to track this.

Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2012-05-08T03:35:40+00:00

Conflicts:
	drivers/net/ethernet/intel/e1000e/param.c
	drivers/net/wireless/iwlwifi/iwl-agn-rx.c
	drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
	drivers/net/wireless/iwlwifi/iwl-trans.h

Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell.  In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.

In e1000e a conflict arose in the validation code for settings of
adapter->itr.  'net-next' had more sophisticated logic so that
logic was used.

Signed-off-by: David S. Miller