kernel/drivers/net/ethernet/mellanox, branch linux-4.3.y

net/mlx5_core: Fix trimming down IRQ number

2016-01-31T19:25:52Z

[ Upstream commit 0b6e26ce89391327d955a756a7823272238eb867 ] With several ConnectX-4 cards installed on a server, one may receive irqn > 255 from the kernel API, which we mistakenly trim to 8bit. This causes EQ creation failure with the following stack trace: [] dump_stack+0x48/0x64 [] __setup_irq+0x3a1/0x4f0 [] request_threaded_irq+0x120/0x180 [] ? mlx5_eq_int+0x450/0x450 [mlx5_core] [] mlx5_create_map_eq+0x1e4/0x2b0 [mlx5_core] [] alloc_comp_eqs+0xb1/0x180 [mlx5_core] [] mlx5_dev_init+0x5e9/0x6e0 [mlx5_core] [] init_one+0x99/0x1c0 [mlx5_core] [] local_pci_probe+0x4c/0xa0 Fixing it by changing of the irqn type from u8 to unsigned int to support values > 255 Fixes: 61d0e73e0a5a ('net/mlx5_core: Use the the real irqn in eq->irqn') Reported-by: Jiri Pirko Signed-off-by: Doron Tsur Signed-off-by: Matan Barak Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net/mlx4_core: Fix sleeping while holding spinlock at rem_slave_counters

2015-12-15T05:40:58Z

[ Upstream commit f5adbfee72282bb1f456d52b04adacd4fe6ac502 ] When cleaning slave's counter resources, we hold a spinlock that protects the slave's counters list. As part of the clean, we call __mlx4_clear_if_stat which calls mlx4_alloc_cmd_mailbox which is a sleepable function. In order to fix this issue, hold the spinlock, and copy all counter indices into a temporary array, and release the spinlock. Afterwards, iterate over this array and free every counter. Repeat this scenario until the original list is empty (a new counter might have been added while releasing the counters from the temporary array). Fixes: b72ca7e96acf ("net/mlx4_core: Reset counters data when freed") Reported-by: Moni Shoua Tested-by: Moni Shoua Signed-off-by: Jack Morgenstein Signed-off-by: Eran Ben Elisha Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net/mlx5e: Added self loopback prevention

2015-12-15T05:40:58Z

[ Upstream commit 66189961e986e53ae39822898fc2ce88f44c61bb ] Prevent outgoing multicast frames from looping back to the RX queue. By introducing new HW capability self_lb_en_modifiable, which indicates the support to modify self_lb_en bit in modify_tir command. When this capability is set we can prevent TIRs from sending back loopback multicast traffic to their own RQs, by "refreshing TIRs" with modify_tir command, on every time new channels (SQs/RQs) are created at device open. This is needed since TIRs are static and only allocated once on driver load, and the loopback decision is under their responsibility. Fixes issues of the kind: "IPv6: eth2: IPv6 duplicate address fe80::e61d:2dff:fe5c:f2e9 detected!" The issue is seen since the IPv6 solicitations multicast messages are loopedback and the network stack thinks they are coming from another host. Fixes: 5c50368f3831 ("net/mlx5e: Light-weight netdev open/stop") Signed-off-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

2015-10-28T03:27:11Z

When doing memcpy/memset of EQEs, we should use sizeof struct mlx4_eqe as the base size and not caps.eqe_size which could be bigger. If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt data in the master context. When using a 64 byte stride, the memcpy copied over 63 bytes to the slave_eq structure. This resulted in copying over the entire eqe of interest, including its ownership bit -- and also 31 bytes of garbage into the next WQE in the slave EQ -- which did NOT include the ownership bit (and therefore had no impact). However, once the stride is increased to 128, we are overwriting the ownership bits of *three* eqes in the slave_eq struct. This results in an incorrect ownership bit for those eqes, which causes the eq to seem to be full. The issue therefore surfaced only once 128-byte EQEs started being used in SRIOV and (overarchitectures that have 128/256 byte cache-lines such as PPC) - e.g after commit 77507aa249ae "net/mlx4_core: Enable CQE/EQE stride support". Fixes: 08ff32352d6f ('mlx4: 64-byte CQE/EQE support') Signed-off-by: Carol L Soto Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller

net/mlx4_en: Explicitly set no vlan tags in WQE ctrl segment when no vlan is present

2015-10-28T03:27:09Z

We do not set the ins_vlan field to zero when no vlan id is present in the packet. Since WQEs in the TX ring are not zeroed out between uses, this oversight could result in having vlan flags present in the WQE ctrl segment when no vlan is preset. Fixes: e38af4faf01d ('net/mlx4_en: Add support for hardware accelerated 802.1ad vlan') Reported-by: Gideon Naim Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller

mlxsw: core: Fix race condition in __mlxsw_emad_transmit

2015-10-15T13:03:06Z

Under certain conditions EMAD responses can be returned from the device even before setting trans_active. This will cause the EMAD Rx listener to drop the EMAD response - as there are no active transactions - and timeouts will be generated. Fix this by setting trans_active before transmitting the EMAD skb. Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events") Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

mlxsw: Fix bug in __mlxsw_item_bit_array_offset

2015-10-11T12:08:09Z

When calculating the shift needed in order to access a bit array element in a byte, we should multiply the index by the element size and not assume it is fixed at 2-bits. Fixes: 93c1edb27f9e ("mlxsw: Introduce Mellanox switch driver core") Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

mlxsw: switchx2: changing order of exit fallbacks

2015-10-11T12:08:08Z

Fixes: 31557f0f9755 ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support") Signed-off-by: Elad Raz Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

net/mlx5e: Disable VLAN filter in promiscuous mode

2015-10-09T14:43:43Z

When the device was set to promiscuous mode, we didn't disable VLAN filtering, which is wrong behaviour, fix that. Now when the device is set to promiscuous mode RX packets sent over any VLAN (or no VLAN tag at all) will be accepted. Signed-off-by: Achiad Shochat Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller

net/mlx5: Fix typo in mlx5_query_port_pvlc

2015-10-09T14:43:43Z

We used the wrong register name for querying the PVLC register Fixes: a124d13ef59e ('net/mlx5_core: Add more query port helpers') Signed-off-by: Jiri Pirko Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller