netdev - Re: [PATCH net] tcp: fix skb_copy

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

Date:   Thu, 27 Apr 2023 20:13:37 -0600
From:   David Ahern <dsahern@...nel.org>
To:     Xin Long <lucien.xin@...il.com>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        eric.dumazet@...il.com, Willem de Bruijn <willemb@...gle.com>,
        Coco Li <lixiaoyan@...gle.com>
Subject: Re: [PATCH net] tcp: fix skb_copy_ubufs() vs BIG TCP

On 4/27/23 6:40 PM, Xin Long wrote:
> 
> I just ran David's test scripts in a metal machine:
> 
> There seem memleak with this patch, and the performance is impaired too:
> 
> # free -h
>               total        used        free      shared  buff/cache  
> available
> Mem:           31Gi       999Mi        30Gi        12Mi       303Mi    
>    30Gi


I can confirm the memleak; thanks for noticing that. It is really easy
to reproduce on a real nic by just running tcpdump with large tso packets.



> 
> I could also see some call trace:
> 
> [  271.416989] warn_alloc: 640 callbacks suppressed
> [  271.417006] lt-iperf3: page allocation failure: order:1,
> mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0-1
> [  271.432684] CPU: 1 PID: 2218 Comm: lt-iperf3 Tainted: G S            
>     6.3.0.net0 #10
> [  271.440783] Hardware name: Supermicro
> X9DRH-7TF/7F/iTF/iF/X9DRH-7TF/7F/iTF/iF, BIOS 3.2  06/04/2015
> [  271.449831] Call Trace:
> [  271.452276]  <IRQ>
> [  271.454286]  dump_stack_lvl+0x36/0x50
> [  271.457953]  warn_alloc+0x11b/0x190
> [  271.461445]  __alloc_pages_slowpath.constprop.119+0xcb9/0xd40
> [  271.467192]  __alloc_pages+0x32d/0x340
> [  271.470944]  skb_copy_ubufs+0x11b/0x630

I did not trigger this ... perhaps due to memory pressure from the leak?

performance wise, veth hits the skb_copy_ubufs when the packet crosses
the namespace, so ZC performance (with and without hugepages ) lags
non-ZC for the same host use case.