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]
Date:   Tue, 10 Jul 2018 12:19:02 +0300
From:   Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
To:     Saeed Mahameed <saeedm@....mellanox.co.il>
Cc:     netdev <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Gal Pressman <galp@...lanox.com>
Subject: Re: [BUG] mlx5 have problems with ipv4-ipv6 tunnels in linux 4.4

On 10.07.2018 01:31, Saeed Mahameed wrote:
> On Tue, Jul 3, 2018 at 10:45 PM, Konstantin Khlebnikov
> <khlebnikov@...dex-team.ru> wrote:
>> I'm seeing problems with tunnelled traffic with Mellanox Technologies
>> MT27710 Family [ConnectX-4 Lx] using vanilla driver from linux 4.4.y
>>
>> Packets with payload bigger than 116 bytes are not exmited.
>> Smaller packets and normal ipv6 works fine.
>>
> 
> Hi Konstantin,
> 
> Is this true for all ipv6 traffic or just ipv4-ipv6 tunnels ?
> 
> what is the skb_network_offset(skb) for such packet ?
> 
>> In linux 4.9, 4.14 and out-of-tree driver everything seems fine for now.
>> It's hard to guess or bisect commit: there are a lot of changes and
>> something wrong with driver or swiotlb in 4.7..4.8.
>> 4.6 is affected too - so this should be something between 4.6 and 4.9
>>
>> Probably this case was fixed indirectly by adding some kind of offload and
>> non-offloaded path is still broken.
>> Please give me a hint: which commit could it be.
>>
> 
> I suspect it works in a newer kernel since we introduced on 4.7/4.8:

Yes, this works. Thank you.

Problem was with VLAN rather than tunnel.

This hunk from first patch is enough:
-#define MLX5E_MIN_INLINE ETH_HLEN
+#define MLX5E_MIN_INLINE (ETH_HLEN + VLAN_HLEN)

In my case full data path looks like

( tcp -> ipip6 -> veth ) -> netns-to-host -> ( veth -> vlan at mlx5 )

Tunnelled traffic also goes to vlan, while most of other traffic goes
through non-tagged interface and worked fine.

max_inline is 226 so (226 - vlan - ethernet - ipv6 - ipv4 - tcp)
leaves exactly 116 bytes for payload.

> 
> commit e3a19b53cbb0e6738b7a547f262179065b72e3fa
> Author: Matthew Finlay <matt@...lanox.com>
> Date:   Thu Jun 30 17:34:47 2016 +0300
> 
>      net/mlx5e: Copy all L2 headers into inline segment
> 
>      ConnectX4-Lx uses an inline wqe mode that currently defaults to
>      requiring the entire L2 header be included in the wqe.
>      This patch fixes mlx5e_get_inline_hdr_size() to account for
>      all L2 headers (VLAN, QinQ, etc) using skb_network_offset(skb).
> 
>      Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files")
>      Signed-off-by: Matthew Finlay <matt@...lanox.com>
>      Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>
>      Signed-off-by: David S. Miller <davem@...emloft.net>
> 
> 
> 
> commit ae76715d153e33c249b6850361e4d8d775388b5a
> Author: Hadar Hen Zion <hadarh@...lanox.com>
> Date:   Sun Jul 24 16:12:39 2016 +0300
> 
>      net/mlx5e: Check the minimum inline header mode before xmit
> 
> and then some fixes on top of it, such as:
> 
> commit f600c6088018d1dbc5777d18daa83660f7ea4a64
> Author: Eran Ben Elisha <eranbe@...lanox.com>
> Date:   Thu Jan 25 11:18:09 2018 +0200
> 
>      net/mlx5e: Verify inline header size do not exceed SKB linear size
> 
> 
> anyhow, can you try the above patches one by one  on 4.4.y and see if it helps ?
> 
> 
> Thanks,
> Saeed
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ