linux-toradex.git/drivers/infiniband/ulp/ipoib, branch v3.4.32

IPoIB: Fix use-after-free of multicast object

2012-10-07T15:32:28+00:00

commit bea1e22df494a729978e7f2c54f7bda328f74bc3 upstream.

Fix a crash in ipoib_mcast_join_task().  (with help from Or Gerlitz)

Commit c8c2afe360b7 ("IPoIB: Use rtnl lock/unlock when changing device
flags") added a call to rtnl_lock() in ipoib_mcast_join_task(), which
is run from the ipoib_workqueue, and hence the workqueue can't be
flushed from the context of ipoib_stop().

In the current code, ipoib_stop() (which doesn't flush the workqueue)
calls ipoib_mcast_dev_flush(), which goes and deletes all the
multicast entries.  This takes place without any synchronization with
a possible running instance of ipoib_mcast_join_task() for the same
ipoib device, leading to a crash due to NULL pointer dereference.

Fix this by making sure that the workqueue is flushed before
ipoib_mcast_dev_flush() is called.  To make that possible, we move the
RTNL-lock wrapped code to ipoib_mcast_join_finish().

Signed-off-by: Patrick McHardy 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

IB: Change CQE "csum_ok" field to a bit flag

2012-03-08T20:34:27+00:00

Use a bit in wc_flags rather then a whole integer to hold the
"checksum OK" flag.  By itself, this change doesn't reduce the size of
struct ib_wc on 64bit machines -- it stays on 56 bytes because of
padding.  However, it will allow to add more fields in the future
without enlarging the struct.  Also, it will let us have a unified
approach with future libibverbs checksum offload reporting, because a
bit flag doesn't break the library ABI.

This patch was suggested during conversation with Liran Liss
.

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

IPoIB: Stop lying about hard_header_len and use skb->cb to stash LL addresses

2012-02-08T23:26:54+00:00

Commit a0417fa3a18a ("net: Make qdisc_skb_cb upper size bound
explicit.") made it possible for a netdev driver to use skb->cb
between its header_ops.create method and its .ndo_start_xmit
method.  Use this in ipoib_hard_header() to stash away the LL address
(GID + QPN), instead of the "ipoib_pseudoheader" hack.  This allows
IPoIB to stop lying about its hard_header_len, which will let us fix
the L2 check for GRO.

Signed-off-by: Roland Dreier 
Signed-off-by: David S. Miller

infiniband: ipoib: Sanitize neighbour handling in ipoib_main.c

2011-12-05T20:20:20+00:00

Reduce the number of dst_get_neighbour_noref() calls within a single
call chain.  Primarily by passing the neighbour pointer down to the
helper functions.

Handle dst_get_neighbour_noref() returning NULL in ipoib_start_xmit()
by incrementing the dropped counter and freeing the packet.  We don't
want it to fall through into the ARP/RARP/multicast handling, since
that should only happen when skb_dst() is NULL.

Signed-off-by: David S. Miller 
Acked-by: Roland Dreier

net: Rename dst_get_neighbour{, _raw} to dst_get_neighbour_noref{, _raw}.

2011-12-05T20:20:19+00:00

To reflect the fact that a refrence is not obtained to the
resulting neighbour entry.

Signed-off-by: David S. Miller 
Acked-by: Roland Dreier

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

2011-12-02T18:49:21+00:00

neigh: Add infrastructure for allocating device neigh privates.

2011-11-30T23:46:43+00:00

netdev->neigh_priv_len records the private area length.

This will trigger for neigh_table objects which set tbl->entry_size
to zero, and the first instances of this will be forthcoming.

Signed-off-by: David S. Miller

Merge branches 'cxgb4', 'ipoib', 'misc' and 'qib' into for-next

2011-11-30T02:01:53+00:00

IB: Fix RCU lockdep splats

2011-11-29T21:37:11+00:00

Commit f2c31e32b37 ("net: fix NULL dereferences in check_peer_redir()")
forgot to take care of infiniband uses of dst neighbours.

Many thanks to Marc Aurele who provided a nice bug report and feedback.

Reported-by: Marc Aurele La France 
Signed-off-by: Eric Dumazet 
Cc: David Miller 
Cc: 
Signed-off-by: Roland Dreier

IB/ipoib: Prevent hung task or softlockup processing multicast response

2011-11-29T21:20:02+00:00

This following can occur with ipoib when processing a multicast reponse:

    BUG: soft lockup - CPU#0 stuck for 67s! [ib_mad1:982]
    Modules linked in: ...
    CPU 0:
    Modules linked in: ...
    Pid: 982, comm: ib_mad1 Not tainted 2.6.32-131.0.15.el6.x86_64 #1 ProLiant DL160 G5
    RIP: 0010:[]  [] _spin_unlock_irqrestore+0x17/0x20
    RSP: 0018:ffff8802119ed860  EFLAGS: 00000246
    0000000000000004 RBX: ffff8802119ed860 RCX: 000000000000a299
    RDX: ffff88021086c700 RSI: 0000000000000246 RDI: 0000000000000246
    RBP: ffffffff8100bc8e R08: ffff880210ac229c R09: 0000000000000000
    R10: ffff88021278aab8 R11: 0000000000000000 R12: ffff8802119ed860
    R13: ffffffff8100be6e R14: 0000000000000001 R15: 0000000000000003
    FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 00000000006d4840 CR3: 0000000209aa5000 CR4: 00000000000406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Call Trace:
    [] ? ipoib_mcast_send+0x157/0x480 [ib_ipoib]
    [] ? apic_timer_interrupt+0xe/0x20
    [] ? apic_timer_interrupt+0xe/0x20
    [] ? ipoib_path_lookup+0x124/0x2d0 [ib_ipoib]
    [] ? ipoib_start_xmit+0x17c/0x430 [ib_ipoib]
    [] ? dev_hard_start_xmit+0x2c8/0x3f0
    [] ? sch_direct_xmit+0x15a/0x1c0
    [] ? dev_queue_xmit+0x388/0x4d0
    [] ? ipoib_mcast_join_finish+0x2c7/0x510 [ib_ipoib]
    [] ? ipoib_mcast_sendonly_join_complete+0x1b8/0x1f0 [ib_ipoib]
    [] ? mcast_work_handler+0x1a6/0x710 [ib_sa]
    [] ? ib_send_mad+0xfe/0x3c0 [ib_mad]
    [] ? ib_get_cached_lmc+0xa3/0xb0 [ib_core]
    [] ? join_handler+0xeb/0x200 [ib_sa]
    [] ? ib_sa_mcmember_rec_callback+0x5c/0xa0 [ib_sa]
    [] ? recv_handler+0x3c/0x70 [ib_sa]
    [] ? ib_mad_completion_handler+0x844/0x9d0 [ib_mad]
    [] ? ib_mad_completion_handler+0x0/0x9d0 [ib_mad]
    [] ? worker_thread+0x170/0x2a0
    [] ? autoremove_wake_function+0x0/0x40
    [] ? worker_thread+0x0/0x2a0
    [] ? kthread+0x96/0xa0
    [] ? child_rip+0xa/0x20

Coinciding with stack trace is the following message:

    ib0: ib_address_create failed

The code below in ipoib_mcast_join_finish() will note the above
failure in the address handle but otherwise continue:

                ah = ipoib_create_ah(dev, priv->pd, &av);
                if (!ah) {
                        ipoib_warn(priv, "ib_address_create failed\n");
                } else {

The while loop at the bottom of ipoib_mcast_join_finish() will attempt
to send queued multicast packets in mcast->pkt_queue and eventually
end up in ipoib_mcast_send():

        if (!mcast->ah) {
                if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
                        skb_queue_tail(&mcast->pkt_queue, skb);
                else {
                        ++dev->stats.tx_dropped;
                        dev_kfree_skb_any(skb);
                }

My read is that the code will requeue the packet and return to the
ipoib_mcast_join_finish() while loop and the stage is set for the
"hung" task diagnostic as the while loop never sees a non-NULL ah, and
will do nothing to resolve.

There are GFP_ATOMIC allocates in the provider routines, so this is
possible and should be dealt with.

The test that induced the failure is associated with a host SM on the
same server during a shutdown.

This patch causes ipoib_mcast_join_finish() to exit with an error
which will flush the queued mcast packets.  Nothing is done to unwind
the QP attached state so that subsequent sends from above will retry
the join.

Reviewed-by: Ram Vepa 
Reviewed-by: Gary Leshner 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Roland Dreier