From: Greg Kroah-Hartman <gre...@linuxfoundation.org>
From: Danielle Ratson <daniel...@nvidia.com>
commit edcbf5137f093b5502f5f6b97cce3cbadbde27aa upstream.
When mirroring to a gretap in hardware the device expects to be
programmed with the egress port and all the encapsulating headers. This
requires the driver to resolve the path the packet will take in the
software data path and program the device accordingly.
If the path cannot be resolved (in this case because of an unresolved
neighbor), then mirror installation fails until the path is resolved.
This results in a race that causes the test to sometimes fail.
Fix this by setting the neighbor's state to permanent, so that it is
always valid.
Fixes: b5b029399fa6d ("selftests: forwarding: mirror_gre_bridge_1d_vlan: Add
STP test")
Signed-off-by: Danielle Ratson <daniel...@nvidia.com>
Reviewed-by: Petr Machata <pe...@nvidia.com>
Signed-off-by: Ido Schimmel <ido...@nvidia.com>
Signed-off-by: Jakub Kicinski <k...@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d_vlan.sh | 9
+++++++++
1 file changed, 9 insertions(+)
--- a/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d_vlan.sh
+++ b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d_vlan.sh
@@ -86,11 +86,20 @@ test_ip6gretap()
test_gretap_stp()
{
+ # Sometimes after mirror installation, the neighbor's state is not
valid.
+ # The reason is that there is no SW datapath activity related to the
+ # neighbor for the remote GRE address. Therefore whether the
corresponding
+ # neighbor will be valid is a matter of luck, and the test is thus racy.
+ # Set the neighbor's state to permanent, so it would be always valid.
+ ip neigh replace 192.0.2.130 lladdr $(mac_get $h3) \
+ nud permanent dev br2
full_test_span_gre_stp gt4 $swp3.555 "mirror to gretap"
}
test_ip6gretap_stp()
{
+ ip neigh replace 2001:db8:2::2 lladdr $(mac_get $h3) \
+ nud permanent dev br2
full_test_span_gre_stp gt6 $swp3.555 "mirror to ip6gretap"
}
