Thread (12 messages) flat view 12 messages, 3 authors, 2021-06-22

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

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-06-22 19:04:35

On Tue, 22 Jun 2021 20:47:57 +0200 Eric Dumazet wrote:
On 6/22/21 8:09 PM, Jakub Kicinski wrote:
quoted
On Tue, 22 Jun 2021 19:48:43 +0200 Eric Dumazet wrote:  
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help