@@ -1077,7 +1077,7 @@ static int __ip_append_data(struct sock *sk,
if ((flags & MSG_MORE) && !has_sg)
alloclen = mtu;
- else if (!paged)
+ else if (!paged && (fraglen < SKB_MAX_ALLOC || !has_sg))
alloclen = fraglen;
else {
alloclen = min_t(int, fraglen, MAX_HEADER);
@@ -1585,7 +1585,7 @@ static int __ip6_append_data(struct sock *sk,
if ((flags & MSG_MORE) && !has_sg)
alloclen = mtu;
- else if (!paged)
+ else if (!paged && (fraglen < SKB_MAX_ALLOC || !has_sg))
alloclen = fraglen;
else {
alloclen = min_t(int, fraglen, MAX_HEADER);
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. This is entirely avoidable, we can use an skb with frags. af_unix solves a similar problem by limiting the head length to SKB_MAX_ALLOC. This seems like a good and simple approach. It means that UDP messages > 16kB will now use fragments if underlying device supports SG, if extra allocator pressure causes regressions in real workloads we can switch to trying the large allocation first and falling back. Reported-by: Dave Jones <dsj@fb.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> --- net/ipv4/ip_output.c | 2 +- net/ipv6/ip6_output.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)