Re: [PATCH net-next] ip: avoid OOM kills with large UDP sends over loopback
From: Paolo Abeni <pabeni@redhat.com>
Date: 2021-06-22 10:07:40
On Mon, 2021-06-21 at 16:13 -0700, Jakub Kicinski wrote:
Dave observed number of machines hitting OOM on the UDP send path. The workload seems to be sending large UDP packets over loopback. Since loopback has MTU of 64k kernel will try to allocate an skb with up to 64k of head space. This has a good chance of failing under memory pressure. What's worse if the message length is <32k the allocation may trigger an OOM killer.
Out of sheer curiosity, are there a large number of UDP sockets in such workload? did you increase rmem_default/rmem_max? If so, could tuning udp_mem help?
quoted hunk ↗ jump to hunk
include/net/sock.h | 11 +++++++++++ net/ipv4/ip_output.c | 19 +++++++++++++++++-- net/ipv6/ip6_output.c | 19 +++++++++++++++++-- 3 files changed, 45 insertions(+), 4 deletions(-)diff --git a/include/net/sock.h b/include/net/sock.h index 7a7058f4f265..4134fb718b97 100644 --- a/include/net/sock.h +++ b/include/net/sock.h@@ -924,6 +924,17 @@ static inline gfp_t sk_gfp_mask(const struct sock *sk, gfp_t gfp_mask) return gfp_mask | (sk->sk_allocation & __GFP_MEMALLOC); } +static inline void sk_allocation_push(struct sock *sk, gfp_t flag, gfp_t *old) +{ + *old = sk->sk_allocation; + sk->sk_allocation |= flag; +} + +static inline void sk_allocation_pop(struct sock *sk, gfp_t old) +{ + sk->sk_allocation = old; +} + static inline void sk_acceptq_removed(struct sock *sk) { WRITE_ONCE(sk->sk_ack_backlog, sk->sk_ack_backlog - 1);diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index c3efc7d658f6..a300c2c65d57 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c@@ -1095,9 +1095,24 @@ static int __ip_append_data(struct sock *sk, alloclen += rt->dst.trailer_len; if (transhdrlen) { - skb = sock_alloc_send_skb(sk, - alloclen + hh_len + 15, + size_t header_len = alloclen + hh_len + 15; + gfp_t sk_allocation; + + if (header_len > PAGE_SIZE) + sk_allocation_push(sk, __GFP_NORETRY, + &sk_allocation);
Could an additional __GFP_NOWARN be relevant here? Thanks! Paolo