netdev - Re: [net 09/10] net/mlx5e: Don't offload internal port if filter device is out device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKpbOAT=i2_j7uSXNwbcES04aDm64YEJa=6YD4Bdzneww4Epag@mail.gmail.com>
Date: Wed, 23 Oct 2024 11:32:34 +0200
From: Frode Nordahl <frode.nordahl@...onical.com>
To: Saeed Mahameed <saeedm@...dia.com>, Jianbo Liu <jianbol@...dia.com>, 
	Ariel Levkovich <lariel@...dia.com>
Cc: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, 
	Tariq Toukan <tariqt@...dia.com>, Saeed Mahameed <saeed@...nel.org>
Subject: Re: [net 09/10] net/mlx5e: Don't offload internal port if filter
 device is out device

On Thu, Oct 12, 2023 at 9:53 PM Saeed Mahameed <saeed@...nel.org> wrote:
>
> From: Jianbo Liu <jianbol@...dia.com>
>
> In the cited commit, if the routing device is ovs internal port, the
> out device is set to uplink, and packets go out after encapsulation.
>
> If filter device is uplink, it can trigger the following syndrome:
> mlx5_core 0000:08:00.0: mlx5_cmd_out_err:803:(pid 3966): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xcdb051), err(-22)
>
> Fix this issue by not offloading internal port if filter device is out
> device. In this case, packets are not forwarded to the root table to
> be processed, the termination table is used instead to forward them
> from uplink to uplink.

This patch breaks forwarding for in production use cases with hardware
offload enabled. In said environments, we do not see the above
mentioned syndrome, so it appears the logic change in this patch hits
too wide.

I do not know the details and inner workings of the constructs
outlined above, can you explain how this is intended to work to help
our understanding of how to approach a fix to this?

Flow steering dumps from a system showing broken and working behavior
(same kernel with this patch reverted) have been attached to
https://launchpad.net/bugs/2085018.

-- 
Frode Nordahl

> Fixes: 100ad4e2d758 ("net/mlx5e: Offload internal port as encap route device")
> Signed-off-by: Jianbo Liu <jianbol@...dia.com>
> Reviewed-by: Ariel Levkovich <lariel@...dia.com>
> Signed-off-by: Saeed Mahameed <saeedm@...dia.com>
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c
> index 1730f6a716ee..b10e40e1a9c1 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c
> @@ -24,7 +24,8 @@ static int mlx5e_set_int_port_tunnel(struct mlx5e_priv *priv,
>
>         route_dev = dev_get_by_index(dev_net(e->out_dev), e->route_dev_ifindex);
>
> -       if (!route_dev || !netif_is_ovs_master(route_dev))
> +       if (!route_dev || !netif_is_ovs_master(route_dev) ||
> +           attr->parse_attr->filter_dev == e->out_dev)
>                 goto out;
>
>         err = mlx5e_set_fwd_to_int_port_actions(priv, attr, e->route_dev_ifindex,
> --
> 2.41.0
>
>