user/sven/linux.git/tools/testing/selftests/drivers, branch v5.4.249

selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets

2022-04-27T11:50:47Z

[ Upstream commit 044011fdf162c5dd61c02841930c8f438a9adadb ] The test verifies that packets are correctly flooded by the bridge and the VXLAN device by matching on the encapsulated packets at the other end. However, if packets other than those generated by the test also ingress the bridge (e.g., MLD packets), they will be flooded as well and interfere with the expected count. Make the test more robust by making sure that only the packets generated by the test can ingress the bridge. Drop all the rest using tc filters on the egress of 'br0' and 'h1'. In the software data path, the problem can be solved by matching on the inner destination MAC or dropping unwanted packets at the egress of the VXLAN device, but this is not currently supported by mlxsw. Fixes: 94d302deae25 ("selftests: mlxsw: Add a test for VxLAN flooding") Signed-off-by: Ido Schimmel Reviewed-by: Amit Cohen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

selftests: mlxsw: qos_mc_aware: Specify arping timeout as an integer

2020-06-07T11:18:52Z

[ Upstream commit 46ca11177ed593f39d534f8d2c74ec5344e90c11 ] Starting from iputils s20190709 (used in Fedora 31), arping does not support timeout being specified as a decimal: $ arping -c 1 -I swp1 -b 192.0.2.66 -q -w 0.1 arping: invalid argument: '0.1' Previously, such timeouts were rounded to an integer. Fix this by specifying the timeout as an integer. Fixes: a5ee171d087e ("selftests: mlxsw: qos_mc_aware: Add a test for UC awareness") Signed-off-by: Amit Cohen Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

selftests: mlxsw: qos_mc_aware: Fix mausezahn invocation

2020-01-23T07:22:53Z

commit fef6d6704944c7be72fd2b77c021f1aed3d5df0d upstream. Mausezahn does not recognize "own" as a keyword on source IP address. As a result, the MC stream is not running at all, and therefore no UC degradation can be observed even in principle. Fix the invocation, and tighten the test: due to the minimum shaper configured at the MC TCs, we always expect about 20% degradation. Fail the test if it is lower. Fixes: 573363a68f27 ("selftests: mlxsw: Add qos_lib.sh") Signed-off-by: Petr Machata Reported-by: Amit Cohen Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

selftests: mlxsw: Adjust test to recent changes

2019-11-15T20:14:38Z

mlxsw does not support VXLAN devices with a physical device attached and vetoes such configurations upon enslavement to an offloaded bridge. Commit 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level") changed the VXLAN device to be an upper of the physical device which causes mlxsw to veto the creation of the VXLAN device with "Unknown upper device type". This is OK as this configuration is not supported, but it prevents us from testing bad flows involving the enslavement of VXLAN devices with a physical device to a bridge, regardless if the physical device is an mlxsw netdev or not. Adjust the test to use a dummy device as a physical device instead of a mlxsw netdev. Fixes: 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level") Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller

mlxsw: spectrum: Clear VLAN filters during port initialization

2019-09-27T18:33:19Z

When a port is created, its VLAN filters are not cleared by the firmware. This causes tagged packets to be later dropped by the ingress STP filters, which default to DISCARD state. The above did not matter much until commit b5ce611fd96e ("mlxsw: spectrum: Add devlink-trap support") where we exposed the drop reason to users. Without this patch, the drop reason users will see is not consistent. If a port is enslaved to a VLAN-aware bridge and a packet with an invalid VLAN tries to ingress the bridge, it will be dropped due to ingress STP filter. If the VLAN is later enabled and then disabled, the packet will be dropped by the ingress VLAN filter despite the above being a seemingly NOP operation. Fix this by clearing all the VLAN filters during port initialization. Adjust the test accordingly. Fixes: b5ce611fd96e ("mlxsw: spectrum: Add devlink-trap support") Reported-by: Alex Kushnarov Tested-by: Alex Kushnarov Acked-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

selftests: mlxsw: Add a test case for devlink-trap

2019-08-21T19:58:39Z

Test generic devlink-trap functionality over mlxsw. These tests are not specific to a single trap, but do not check the devlink-trap common infrastructure either. Currently, the only test case is device deletion (by reloading the driver) while packets are being trapped. Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

selftests: mlxsw: Add test cases for devlink-trap L2 drops

2019-08-21T19:58:39Z

Test that each supported packet trap is triggered under the right conditions and that packets are indeed dropped and not forwarded. Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

selftests: devlink_trap: Add test cases for devlink-trap

2019-08-17T19:40:09Z

Add test cases for devlink-trap on top of the netdevsim implementation. The tests focus on the devlink-trap core infrastructure and user space API. They test both good and bad flows and also dismantle of the netdev and devlink device used to report trapped packets. This allows device drivers to focus their tests on device-specific functionality. Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

selftests: netdevsim: add devlink regions tests

2019-08-15T19:02:44Z

Test netdevsim devlink region implementation. Signed-off-by: Jiri Pirko Tested-by: Jakub Kicinski Acked-by: Jakub Kicinski Signed-off-by: David S. Miller

selftests: netdevsim: add devlink params tests

2019-08-15T19:01:22Z

Test recently added netdevsim devlink param implementation. Signed-off-by: Jiri Pirko Tested-by: Jakub Kicinski Acked-by: Jakub Kicinski Signed-off-by: David S. Miller