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

Merge branches 'cma', 'cxgb4', 'flowsteer', 'ipoib', 'misc', 'mlx4', 'mlx5', 'ocrdma', 'qib', 'srp' and 'usnic' into for-next

2014-01-23T07:24:13+00:00

IPoIB: Report operstate consistently when brought up without a link

2014-01-23T07:01:05+00:00

After booting without a working link, "ip link" shows:

 5: mlx4_ib1:  mtu 2044 qdisc pfifo_fast
 state DOWN qlen 256
    ...
 7: mlx4_ib1.8003@mlx4_ib1:  mtu 2044 qdisc
 pfifo_fast state DOWN qlen 256
    ...

Then after connecting and disconnecting the link, which should result
in exactly the same state as before, it shows:

 5: mlx4_ib1:  mtu 2044 qdisc pfifo_fast
 state DOWN qlen 256
    ...
 7: mlx4_ib1.8003@mlx4_ib1:  mtu 2044 qdisc
 pfifo_fast state LOWERLAYERDOWN qlen 256
    ...

Notice the (now correct) LOWERLAYERDOWN operstate shown for the
mlx4_ib1.8003 interface. Ideally the identical state would be shown
right after boot.

The problem is related to the calling of netif_carrier_off() in
network drivers.  For a long time it was known that doing
netif_carrier_off() before registering the netdevice would result in
the interface's operstate being shown as UNKNOWN if the device was
brought up without a working link. This problem was fixed in commit
8f4cccbbd92 ('net: Set device operstate at registration time'), but
still there remains the minor inconsistency demonstrated above.

This patch fixes it by moving ipoib's call to netif_carrier_off() into
the .ndo_open method, which is where network drivers ordinarily do it.
With the patch when doing the same test as above, the operstate of
mlx4_ib1.8003 is shown as LOWERLAYERDOWN right after boot.

Signed-off-by: Michal Schmidt 
Acked-by: Erez Shitrit 
Signed-off-by: Roland Dreier

IB/core: Add flow steering support for IPoIB UD traffic

2014-01-14T22:06:50+00:00

When creating an IPoIB UD QP, provide a hint to the low level driver
that the QP should support flow-steering.  This means that privileged
user space applications can steer TCP/IP IPoIB traffic from the
network stack, in a similar manner done with Ethernet RAW_PACKET QPs.

The hint is provided through new QP creation flag called NETIF_QP.

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

infiniband: make sure the src net is infiniband when create new link

2014-01-04T01:38:56+00:00

When we create a new infiniband link with uninfiniband device, e.g. `ip link
add link em1 type ipoib pkey 0x8001`. We will get a NULL pointer dereference
cause other dev like Ethernet don't have struct ib_device.

The code path is:
rtnl_newlink
  |-- ipoib_new_child_link
        |-- __ipoib_vlan_add
              |-- ipoib_set_dev_features
                    |-- ib_query_device

Fix this bug by make sure the src net is infiniband when create new link.

Signed-off-by: Hangbin Liu 
Signed-off-by: David S. Miller

IPoIB: lower NAPI weight

2013-11-08T22:42:50+00:00

Since commit 82dc3c63c692 ("net: introduce NAPI_POLL_WEIGHT")
netif_napi_add() produces an error message if a NAPI poll weight
greater than 64 is requested.

Use the standard NAPI weight.

Signed-off-by: Michal Schmidt 
Signed-off-by: Roland Dreier

IPoIB: Start multicast join process only on active ports

2013-11-08T22:42:49+00:00

The driver starts the mcast_join task whenever the netdev interface is
UP without relation to the underlying IB port state.

Until the port state is ACTIVE all the join requests are irrelevant,
and the IB core returns -EINVAL. So the user will see errors such as:
"multicast join failed for ff12:401b:... , status -22".

Instead, have ipoib_mcast_join_task() return when the port is not active.

It will be called again when the port state is changed and the
low-level driver triggers the IB_EVENT_PORT_ACTIVE event or the
IB_EVENT_CLIENT_REREGISTER event.

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

IPoIB: Add path query flushing in ipoib_ib_dev_cleanup

2013-11-08T22:42:49+00:00

The path_rec_completion() callback may be invoked asynchronously even
at the middle of "driver uninit" process.  This can lead to scheduling
a task that tries to touch members of the priv object that are no
longer valid.  For example the function cm_create_tx_qp can attempt to
create qp with no valid priv->pd object.

The following crash is one of the results:
RIP: 0010:[]  [] ipoib_cm_create_tx_qp+0x57/0x90 [ib_ipoib]
Process ipoib (pid: 5916, threadinfo ffff8803786e4000, task ffff8804150e1500)
Stack:
Call Trace:
[] ? get_random_bytes+0x20/0x30
[] ipoib_cm_tx_init+0xca/0x340 [ib_ipoib]
[] ipoib_cm_tx_start+0x215/0x3f0 [ib_ipoib]
[] ? ipoib_cm_tx_start+0x0/0x3f0 [ib_ipoib]
[] worker_thread+0x170/0x2a0
[] ? autoremove_wake_function+0x0/0x40
[] ? worker_thread+0x0/0x2a0
[] kthread+0x96/0xa0
[] child_rip+0xa/0x20
[] ? kthread+0x0/0xa0
[] ? child_rip+0x0/0x20

Fix that by flushing all pending path queries at this point.

Signed-off-by: Alex Markuze 
Signed-off-by: Erez Shitrit 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier

IPoIB: Fix usage of uninitialized multicast objects

2013-11-08T22:42:49+00:00

The driver should avoid calling ib_sa_free_multicast on the mcast->mc
object until it finishes its initialization state.  Otherwise we can
crash when ipoib_mcast_dev_flush() attempts to use the uninitialized
multicast object.

Instead, only call wait_for_completion() for multicast entries that
started the join process, meaning that ib_sa_join_multicast() finished.

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

IPoIB: Avoid flushing the driver workqueue on dev_down

2013-11-08T22:42:49+00:00

The driver should not flush the whole workqueue when only one work (the
pkey poll one) needs to be cancelled.  Use cancel_delayed_work_sync()
instead.

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

IPoIB: Fix deadlock between dev_change_flags() and __ipoib_dev_flush()

2013-11-08T22:42:49+00:00

When ipoib interface is going down it takes all of its children with
it, under mutex.

For each child, dev_change_flags() is called.  That function calls
ipoib_stop() via the ndo, and causes flush of the workqueue.
Sometimes in the workqueue an __ipoib_dev_flush work() is waiting and
when invoked tries to get the same mutex, which leads to a deadlock,
as seen below.

The solution is to switch to rw-sem instead of mutex.

The deadlock:
[11028.165303]  [] ? vgacon_scroll+0x107/0x2e0
[11028.171844]  [] schedule_timeout+0x215/0x2e0
[11028.178465]  [] ? perf_event_task_sched_out+0x33/0x80
[11028.185962]  [] wait_for_common+0x123/0x180
[11028.192491]  [] ? default_wake_function+0x0/0x20
[11028.199504]  [] wait_for_completion+0x1d/0x20
[11028.206224]  [] flush_cpu_workqueue+0x61/0x90
[11028.212948]  [] ? wq_barrier_func+0x0/0x20
[11028.219375]  [] flush_workqueue+0x54/0x80
[11028.225712]  [] ipoib_mcast_stop_thread+0x66/0x90 [ib_ipoib]
[11028.233988]  [] ipoib_ib_dev_down+0x6a/0x100 [ib_ipoib]
[11028.241678]  [] ipoib_stop+0x8a/0x140 [ib_ipoib]
[11028.248692]  [] dev_close+0x71/0xc0
[11028.254447]  [] dev_change_flags+0xa1/0x1d0
[11028.261062]  [] ipoib_stop+0x10b/0x140 [ib_ipoib]
[11028.268172]  [] dev_close+0x71/0xc0
[11028.273922]  [] dev_change_flags+0xa1/0x1d0
[11028.280452]  [] devinet_ioctl+0x5eb/0x6a0
[11028.286786]  [] inet_ioctl+0x88/0xa0
[11028.292633]  [] sock_ioctl+0x7a/0x280
[11028.298576]  [] vfs_ioctl+0x22/0xa0
[11028.304326]  [] ? unmap_region+0x110/0x130
[11028.310756]  [] do_vfs_ioctl+0x84/0x580
[11028.316897]  [] sys_ioctl+0x81/0xa0

and

11028.017533]  [] ? perf_event_task_sched_out+0x33/0x80
[11028.025030]  [] ? apic_timer_interrupt+0xe/0x20
[11028.031945]  [] __mutex_lock_slowpath+0x13e/0x180
[11028.039053]  [] mutex_lock+0x2b/0x50
[11028.044910]  [] __ipoib_ib_dev_flush+0x37/0x210 [ib_ipoib]
[11028.052894]  [] ? ipoib_ib_dev_flush_light+0x0/0x20 [ib_ipoib]
[11028.061363]  [] ipoib_ib_dev_flush_light+0x17/0x20 [ib_ipoib]
[11028.069738]  [] worker_thread+0x170/0x2a0
[11028.076068]  [] ? autoremove_wake_function+0x0/0x40
[11028.083374]  [] ? worker_thread+0x0/0x2a0
[11028.089709]  [] kthread+0x96/0xa0
[11028.095266]  [] child_rip+0xa/0x20
[11028.100921]  [] ? kthread+0x0/0xa0
[11028.106573]  [] ? child_rip+0x0/0x20
[11028.112423] INFO: task ifconfig:23640 blocked for more than 120 seconds.

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