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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7b4945782c33f4dbb3b4538fc2c40af86e7c5ae1.camel@mellanox.com>
Date:   Thu, 21 Feb 2019 22:35:10 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "gerlitz.or@...il.com" <gerlitz.or@...il.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Or Gerlitz <ogerlitz@...lanox.com>
Subject: Re: mlx5 stable backport help

On Thu, 2019-02-21 at 12:21 +0200, Or Gerlitz wrote:
> On Wed, Feb 20, 2019 at 10:03 PM Saeed Mahameed <saeedm@...lanox.com>
> wrote:
> > On Tue, 2019-02-19 at 22:36 -0800, David Miller wrote:
> > > I need help backporting two changes for -stable.  Namely:
> > Hi Dave Thanks for trying,
> 
> here too
> 
> > > 6707f74be8621ae067d2cf1c4485900e2742c20f ("net/mlx5e: Update hw
> > > flows
> > > when encap source mac changed")
> > 
> > The fixes tag of the above commit is wrong and it should have been
> > 
> > commit e32ee6c78efa6a32bff782bbe7a9970b018996ca
> > Author: Eli Britstein <elibr@...lanox.com>
> > Date:   Mon Dec 3 17:09:54 2018 +0200
> > 
> >     net/mlx5e: Support tunnel encap over tagged Ethernet
> > 
> > Before this patch we didn't have the support for "tunnel encap over
> > tagged Ethernet" which introduced the whole route_dev logic to
> > generate
> > the encap headers, so the patch should only exist in -rc, let's
> > just skip it.
> 
> Hi Saeed,
> 
> The issue exists prior to the commit you mentioned, we are doing this
> code since day one of
> tc tunnel offloads support which lacked the neigh update flow
> 
> linux-stable.git]# git grep -pe "eth->h_source"
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c=static void
> gen_vxlan_header_ipv4(struct net_device *out_dev,
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:
> ether_addr_copy(eth->h_source, out_dev->dev_addr);
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c=static void
> gen_vxlan_header_ipv6(struct net_device *out_dev,
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:
> ether_addr_copy(eth->h_source, out_dev->dev_addr);
> 
> later when 232c001398ae ("net/mlx5e: Add support to neighbour update
> flow") was done, we went short
> and did not address the case of source address change. Until the
> commit you mentioned, we didn't have the
> out_dev vs route_dev notion, but the problem exists and it's possible
> to backport the patch by
> 

So we all agree that the offending patch is "net/mlx5e: Support tunnel
encap over tagged Ethernet" even if the issue existed before, 
in order to fix the issue you will have to port not only this patch but
the whole series which claimed to fix the issue, so the fixes tag was
wrong.. this patch on its own is no good.

> [1] using  e->out_dev instead of e->route_dev
> [2] use the hunks from mlx5e_tc_tun_create_header_ipv4/6() in
> mlx5e_create_encap_header_ipv4/6()
> 
> Or.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ