• Or Gerlitz's avatar
    net/mlx5e: Avoid encap flows deletion attempt the 1st time a neigh is resolved · 61c806da
    Or Gerlitz authored
    Currently, we are deleting offloaded encap flows in case the relevant neigh
    becomes unconnected while the encap is valid (a sign that it used to be
    connected), or if the curr neigh mac is different from the cached mac
    (a sign that the remote side changed their mac).
    
    The 2nd check also applies when the neigh becomes connected on the 1st
    time (we start with zero mac). Before the offending commit, the deleting
    handler was practically no op, as no flows were offloaded. But since
    that commit, we offload neigh-less encap flows to slow path.
    
    Under mirroring scheme, we go into the delete handler, attempt to unoffload a
    mirror rule which was never set (as we were offloading to slow path) and crash.
    
    Fix that by calling the delete handler only when the encap is valid,
    which covers both cases mentioned above.
    
    Fixes: 5dbe906f ('net/mlx5e: Use a slow path rule instead if vxlan neighbour isn't available')
    Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: default avatarEli Britstein <elibr@mellanox.com>
    Reviewed-by: default avatarPaul Blakey <paulb@mellanox.com>
    Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
    61c806da
en_rep.c 38.5 KB