| 6873a67c | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341538:
ipoib: Notify on modify QP failure only when relevant
Modify QP can fail and it can be acceptable, like when moving from RST to
ERR state, all the rest are not acceptable and a message
MFC r341538:
ipoib: Notify on modify QP failure only when relevant
Modify QP can fail and it can be acceptable, like when moving from RST to
ERR state, all the rest are not acceptable and a message to the log
should be printed.
The current code prints on all failures and many messages like:
"Failed to modify QP to ERROR state" appear, even when supported by the
state machine of the QP object.
Linux commit:
5dc78ad1904db597bdb4427f3ead437aae86f54c
Sponsored by: Mellanox Technologies
show more ...
|
| 5438161b | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341537:
ipoib: increase the non-cm queue length
When a packet needs fragmentation, it might generate more than 3 fragments.
With the queue length 3, all fragments are generated faster than the
MFC r341537:
ipoib: increase the non-cm queue length
When a packet needs fragmentation, it might generate more than 3 fragments.
With the queue length 3, all fragments are generated faster than the
queue is drained, which effectively drops fourth and later fragments on
the floor.
Submitted by: kib@
Sponsored by: Mellanox Technologies
show more ...
|
| d40cf80f | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341536:
ipoib: Don't do a light flush when MTU is unchanged.
When changing the MTU of ibX network interfaces, check that the MTU was really
changed before requesting an update of the multicast
MFC r341536:
ipoib: Don't do a light flush when MTU is unchanged.
When changing the MTU of ibX network interfaces, check that the MTU was really
changed before requesting an update of the multicast rules. Else we might go
into an infinite loop joining and leaving ibX multicast groups towards the
opensm master interface.
Sponsored by: Mellanox Technologies
show more ...
|
| 64a2845f | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341535:
ipoib: correct setting MTU from inside ipoib(4).
It is not enough to set ifnet->if_mtu to change the interface MTU.
System saves the MTU for route in the radix tree, and route cache kee
MFC r341535:
ipoib: correct setting MTU from inside ipoib(4).
It is not enough to set ifnet->if_mtu to change the interface MTU.
System saves the MTU for route in the radix tree, and route cache keeps
the interface MTU as well. Since addition of the multicast group causes
recalculation of MTU, even bringing the interface up changes MTU from
4042 to 1500, which makes the system configuration inconsistent. Worse,
ip_output() prefers route MTU over interface MTU, so large packets are
not fragmented and dropped on floor.
Fix it for ipoib(4) using the same approach (or hack) as was applied
for it_tun/if_tap in r339012. Thanks to bz@ for giving the hint.
Sponsored by: Mellanox Technologies
show more ...
|
| 1cee336d | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341534:
ibcore: Fix clearing of bound device interface.
Binding to a loopback device is not allowed. Make sure the destination
device address is global by clearing the bound device interface.
O
MFC r341534:
ibcore: Fix clearing of bound device interface.
Binding to a loopback device is not allowed. Make sure the destination
device address is global by clearing the bound device interface.
Only do this conditionally, else link local addresses won't work.
Sponsored by: Mellanox Technologies
show more ...
|
| b46f9f1c | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341532:
ibcore: Fix sleeping in atomic when RoCE is used
A couple of places in the CM do
spin_lock_irq(&cm_id_priv->lock);
...
if (cm_alloc_response_msg(work->port, work->mad_recv_
MFC r341532:
ibcore: Fix sleeping in atomic when RoCE is used
A couple of places in the CM do
spin_lock_irq(&cm_id_priv->lock);
...
if (cm_alloc_response_msg(work->port, work->mad_recv_wc, &msg))
However when the underlying transport is RoCE, this leads to a sleeping function
being called with the lock held - the callchain is
cm_alloc_response_msg() ->
ib_create_ah_from_wc() ->
ib_init_ah_from_wc() ->
rdma_addr_find_l2_eth_by_grh() ->
rdma_resolve_ip()
and rdma_resolve_ip() starts out by doing
req = kzalloc(sizeof *req, GFP_KERNEL);
not to mention rdma_addr_find_l2_eth_by_grh() doing
wait_for_completion(&ctx.comp);
to wait for the task that rdma_resolve_ip() queues up.
Fix this by moving the AH creation out of the lock.
Linux commit:
c76161181193985087cd716fdf69b5cb6cf9ee85
Sponsored by: Mellanox Technologies
show more ...
|
| f566e4be | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341530:
ibcore: Fix loopback with rdma-cm.
Trying to validate loopback fails because rtalloc1() resolves system
local addresses to the loopback network interface, lo0. Fix this by
explicitly ch
MFC r341530:
ibcore: Fix loopback with rdma-cm.
Trying to validate loopback fails because rtalloc1() resolves system
local addresses to the loopback network interface, lo0. Fix this by
explicitly checking for loopback during validation of the source
and destination network address. If the source address belongs to
a local network interface and is equal to the destination address,
there is no need to run the destination address through rtalloc1().
Sponsored by: Mellanox Technologies
show more ...
|
| b6e1b807 | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341529:
ibcore: Make sure all VNETs are scanned for VLAN interfaces.
The master network interface and the VLANs may reside in different VNETs.
Make sure that all VNETs are searched when scannin
MFC r341529:
ibcore: Make sure all VNETs are scanned for VLAN interfaces.
The master network interface and the VLANs may reside in different VNETs.
Make sure that all VNETs are searched when scanning for GID entries.
Sponsored by: Mellanox Technologies
show more ...
|
| 77d7dc68 | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341526:
ibcore: Fix an array index check
The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS
(80) elements. Hence compare the array index with that value instead
of with IB_MGMT_M
MFC r341526:
ibcore: Fix an array index check
The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS
(80) elements. Hence compare the array index with that value instead
of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity
reports the following:
Overrunning array class->method_table of 80 8-byte elements at element index 127
(byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class)
(which evaluates to 127).
Linux commit:
2fe2f378dd45847d2643638c07a7658822087836
Sponsored by: Mellanox Technologies
show more ...
|
| 45db2035 | 12-Dec-2018 |
Hans Petter Selasky <[email protected]> |
MFC r341523:
ibcore: Don't access invalid port.
The port number in the listen_id_priv has been observed to be zero which
means no port has been selected. The current code lacks a check for invalid
p
MFC r341523:
ibcore: Don't access invalid port.
The port number in the listen_id_priv has been observed to be zero which
means no port has been selected. The current code lacks a check for invalid
port number.
Sponsored by: Mellanox Technologies
show more ...
|