netdev - Re: [PATCH net-next] ip: avoid OOM kills with large UDP sends over loopback

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: <20210622120426.17ef1acc@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Tue, 22 Jun 2021 12:04:26 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, willemb@...gle.com,
        dsahern@...il.com, yoshfuji@...ux-ipv6.org, Dave Jones <dsj@...com>
Subject: Re: [PATCH net-next] ip: avoid OOM kills with large UDP sends over
 loopback

On Tue, 22 Jun 2021 20:47:57 +0200 Eric Dumazet wrote:
> On 6/22/21 8:09 PM, Jakub Kicinski wrote:
> > On Tue, 22 Jun 2021 19:48:43 +0200 Eric Dumazet wrote:  
> >> I  really thought alloc_skb_with_frags() was already handling low-memory-conditions.
> >>
> >> (alloc_skb_with_frags() is called from sock_alloc_send_pskb())
> >>
> >> If it is not, lets fix it, because af_unix sockets will have the same issue ?  
> > 
> > af_unix seems to cap at SKB_MAX_ALLOC which is order 2, AFAICT.  
> 
> It does not cap to SKB_MAX_ALLOC.
> 
> It definitely attempt big allocations if you send 64KB datagrams.
> 
> Please look at commit d14b56f508ad70eca3e659545aab3c45200f258c
>     net: cleanup gfp mask in alloc_skb_with_frags
> 
> This explains why we do not have __GFP_NORETRY there.

Ah, right, slight misunderstanding.

Just to be 100% clear for UDP send we are allocating up to 64kB 
in the _head_, AFAICT. Allocation of head does not clear GFP_WAIT. 

Your memory was correct, alloc_skb_with_frags() does handle low-memory
when it comes to allocating frags. And what I was saying is af_unix
won't have the same problem as UDP as it caps head's size at
SKB_MAX_ALLOC, and frags are allocated with fallback.

For the UDP case we can either adapt the af_unix approach, and cap head
size to SKB_MAX_ALLOC or try to allocate the full skb and fall back.
Having alloc_skb_with_frags() itself re-balance head <> data
automatically does not feel right, no?