netdev - Re: [PATCH net-next 2/2] mlx4/en_netdev: call notifiers when hw_enc

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] [day] [month] [year] [list]

Date:   Fri, 26 Jul 2019 21:10:29 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "dcaratti@...hat.com" <dcaratti@...hat.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Tariq Toukan <tariqt@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Eran Ben Elisha <eranbe@...lanox.com>
Subject: Re: [PATCH net-next 2/2] mlx4/en_netdev: call notifiers when
 hw_enc_features change

On Fri, 2019-07-26 at 12:39 +0200, Davide Caratti wrote:
> On Thu, 2019-07-25 at 21:27 +0000, Saeed Mahameed wrote:
> > On Thu, 2019-07-25 at 14:25 +0200, Davide Caratti wrote:
> > > On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> > > > On Wed, 2019-07-24 at 16:02 +0200, Davide Caratti wrote:
> > > > > ensure to call netdev_features_change() when the driver flips
> > > > > its
> > > > > hw_enc_features bits.
> > > > > 
> > > > > Signed-off-by: Davide Caratti <dcaratti@...hat.com>
> > > > 
> > > > The patch is correct, 
> > > 
> > > hello Saeed, and thanks for looking at this!
> > > 
> > > > but can you explain how did you come to this ? 
> > > > did you encounter any issue with the current code ?
> > > > 
> > > > I am asking just because i think the whole dynamic changing of
> > > > dev-
> > > > > hw_enc_features is redundant since mlx4 has the
> > > > > featutres_check
> > > > callback.
> > > 
> > > we need it to ensure that vlan_transfer_features() updates
> > > the (new) value of hw_enc_features in the overlying vlan:
> > > otherwise,
> > > segmentation will happen anyway when skb passes from vxlan to
> > > vlan,
> > > if the
> > > vxlan is added after the vlan device has been created (see:
> > > 7dad9937e064
> > > ("net: vlan: add support for tunnel offload") ).
> > > 
> > 
> > but in previous patch you made sure that the vlan always sees the
> > correct hw_enc_features on driver load, we don't need to have this
> > dynamic update mechanism,
> 
> ok, but the mlx4 driver flips the value of hw_enc_features when VXLAN
> tunnels are added or removed. So, assume eth0 is a Cx3-pro, and I do:
>  
>  # ip link add name vlan5 link eth0 type vlan id 5
>  # ip link add dev vxlan6 type vxlan id 6  [...]  dev vlan5
>  
> the value of dev->hw_enc_features is 0 for vlan5, and as a
> consequence
> VXLAN over VLAN traffic becomes segmented by the VLAN, even if eth0,
> at
> the end of this sequence, has the "right" features bits.
> 

your patch handled this issue already, no need for flipping and
updating features if features check ndo will cover the cases we don't
support.

> > features_check ndo should take care of
> > protocols we don't support.
> 
> I just had a look at mlx4_en_features_check(), I see it checks if the
> packet is tunneled in VXLAN and the destination port matches the
> configured value of priv->vxlan_port (when that value is not zero).
> Now:
> 
> On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> > I am asking just because i think the whole dynamic changing of 
> > dev-> hw_enc_features is redundant since mlx4 has the
> > featutres_check
> > callback.
> 
> I read your initial proposal again. Would it be correct if I just use
> patch 1/2, where I add an assignment of
> 
> dev->hw_enc_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | \
>                        NETIF_F_RXCSUM | \
>                        NETIF_F_TSO | NETIF_F_TSO6 | \
>                        NETIF_F_GSO_UDP_TUNNEL | \
>                        NETIF_F_GSO_UDP_TUNNEL_CSUM | \
>                        NETIF_F_GSO_PARTIAL;
> 
> in mlx4_en_init_netdev(), and then remove the code that flips
> dev->hw_enc_features in mlx4_en_add_vxlan_offloads() and
> mlx4_en_del_vxlan_offloads() ?
> 

yes, this is exactly what I meant.

Thanks,
Saeed.