All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, willemb@google.com,
	dsahern@gmail.com, yoshfuji@linux-ipv6.org,
	Dave Jones <dsj@fb.com>
Subject: Re: [PATCH net-next] ip: avoid OOM kills with large UDP sends over loopback
Date: Tue, 22 Jun 2021 12:04:26 -0700	[thread overview]
Message-ID: <20210622120426.17ef1acc@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> (raw)
In-Reply-To: <d4e2cf28-89f9-7c1f-91de-759de2c47fae@gmail.com>

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?

  reply	other threads:[~2021-06-22 19:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 23:13 [PATCH net-next] ip: avoid OOM kills with large UDP sends over loopback Jakub Kicinski
2021-06-22 10:07 ` Paolo Abeni
2021-06-22 16:57   ` Jakub Kicinski
2021-06-22 14:12 ` Eric Dumazet
2021-06-22 16:54   ` Jakub Kicinski
2021-06-22 17:19     ` Jakub Kicinski
2021-06-22 17:49       ` Eric Dumazet
2021-06-22 17:48     ` Eric Dumazet
2021-06-22 18:09       ` Jakub Kicinski
2021-06-22 18:47         ` Eric Dumazet
2021-06-22 19:04           ` Jakub Kicinski [this message]
2021-06-22 19:51             ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210622120426.17ef1acc@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=dsj@fb.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.