Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp159526imu; Wed, 2 Jan 2019 16:38:36 -0800 (PST) X-Google-Smtp-Source: ALg8bN7PtQvB9viozgvzy3d38E8cEydDy8BqCc5xRA5VQ4gKetu8mFoh+q2F968C1tDpeu9UkHFp X-Received: by 2002:a63:1e56:: with SMTP id p22mr15233567pgm.126.1546475916849; Wed, 02 Jan 2019 16:38:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546475916; cv=none; d=google.com; s=arc-20160816; b=DsYVCAnIOVTy2qvTY4dg+uryDdzmKn0xo4SjZMAcSGBWslGBlsISeOsllRUsq1k+6k UZl+Nhic2KL9BSOB4mCsbiDhk0AsuXtbgx0fgJMbSoEN86lh3YDeRqwQN1PIclKcuN0B cgvYFbvK2USwc/eKrC55VWJ50C2lD4kViij/t2apxpx4QGJF4+5VyTHXsh0sBElio9wt LsIEPDJuBT9DEzNGNMf6Yqpyltatz+Gw8S1eEcB5qRA70L1xIpq5YjDDuUHgPBuHLGsU OkYI2xFffKEQZN/pqDkfYfG7N5QlkqNoRrDHHZ3pGYS6SuOQb60FldBOhdoGNpHapL3n 0NVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :subject:cc:to:from:date:dkim-signature; bh=7jOLZApund1vrMmXa18mGVqJGSoStuzJ8CBOA3gKuDw=; b=A9gnAXQI14kYrF736eb++1vtjWqZRTC8EO1JjLCHZviiExqYwBGUDMRrUlU0pXlJ1G TTeoQxZX5gxAtl0UlynNg9KP7NeawyGQSBw+AMJPgypaosV3abhao27FRlZAa5cHbVrN 0zA3v6RZQ6r/dDcTMuPsaCOpXewOLYwMhMKlF8CoI0PRicNnagL5uYR1Dhmzu+Gah1ea 1r8+2uK6+gIW0ah9DtqOwlCO6VoSW3rR0ysRbJmsiZDRV4wbQEuw65YSe/V1xvRl2S9Y fdz9j6Nx+wwsmEVRvebcK0yuY1/GmJ9tMDIn1K4qBx9LzW0BxX5MQfqCvpMZSB+KSJcE Se0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=oxM3Gdeo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g98si50468595plb.99.2019.01.02.16.38.21; Wed, 02 Jan 2019 16:38:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=oxM3Gdeo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727271AbfABVBr (ORCPT + 99 others); Wed, 2 Jan 2019 16:01:47 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:38724 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726886AbfABVBq (ORCPT ); Wed, 2 Jan 2019 16:01:46 -0500 Received: by mail-pf1-f196.google.com with SMTP id q1so15678183pfi.5 for ; Wed, 02 Jan 2019 13:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:user-agent:mime-version; bh=7jOLZApund1vrMmXa18mGVqJGSoStuzJ8CBOA3gKuDw=; b=oxM3GdeoGbmHLLY+WvXY6v4dSjaMW5JgZz22eion/T6d/5+8CxP8NVtNibj2ewKDQh me8NHiFDewKIVBzR6F+xUYdUhNnX+J/pr7Qa1Y8jJYF/qK04r4v8Kp51del1ruVhcbQI LO9jD+N9rs8ceZQxdGt68ZeniViVfefXfAqVYjU6D3dXwwq+z/snVLqVw4289VkOof/Z 0ok6zSmsU1kiqEyn1qX7Wr4auG0UVmIdqIaSEED08O/yyNWzGjpZmYAteixbxUcgLl3S 06abecq9lbH8pj6grYV6Rmco8XUgrkg/Jnsx4ISn5Zszq5vSPFNcji2uqmYcvYxlOf4d S9tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:user-agent :mime-version; bh=7jOLZApund1vrMmXa18mGVqJGSoStuzJ8CBOA3gKuDw=; b=DP3SNOrCKTLsZVqo9BKBbYz4OLfd0VqkYDpsYcTzSX9Qk/hMcULqenAOSllLqzF9o0 gL4noeD6jDkDlk1EjSSY3VZtn+U7Kh+WAjAbRu45i2zpyUPHL+9RxHq1lk+9rq9AacT3 RvU91sRuMknslDzA1ifDboI0wOOP0dWfkZxSuJh+7Fcpi9KV5VeBtH2A2uPX0T5/Af/k J6IqW6VteJ7MGvmop2TrUzPv8AKN/ZCjSI86m9f/sBaiPvR/hkP84Fu0z/+tn2tA/BeE qysrChTMnDPRK4bcurd+wblkU1t407vlEPnL5tecphC4oixU+NphSLaAk39yYJ8iRNUS QD9w== X-Gm-Message-State: AA+aEWbwYAdgOk+hLv2+wEOikOsUCID04Pn7erPntP6RN4kIK+I498co ycJ82glBHDrIV3YcIQ52iXk0Ig== X-Received: by 2002:a62:1b50:: with SMTP id b77mr46131674pfb.36.1546462905048; Wed, 02 Jan 2019 13:01:45 -0800 (PST) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id k24sm79188227pfj.13.2019.01.02.13.01.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 02 Jan 2019 13:01:44 -0800 (PST) Date: Wed, 2 Jan 2019 13:01:43 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: "David S. Miller" , Eric Dumazet cc: Andrew Morton , Willem de Bruijn , Michal Hocko , Vlastimil Babka , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [patch] net, skbuff: do not prefer skb allocation fails early Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic") replaced __GFP_REPEAT in alloc_skb_with_frags() with __GFP_RETRY_MAYFAIL when the allocation may directly reclaim. The previous behavior would require reclaim up to 1 << order pages for skb aligned header_len of order > PAGE_ALLOC_COSTLY_ORDER before failing, otherwise the allocations in alloc_skb() would loop in the page allocator looking for memory. __GFP_RETRY_MAYFAIL makes both allocations failable under memory pressure, including for the HEAD allocation. This can cause, among many other things, write() to fail with ENOTCONN during RPC when under memory pressure. These allocations should succeed as they did previous to dcda9b04713c even if it requires calling the oom killer and additional looping in the page allocator to find memory. There is no way to specify the previous behavior of __GFP_REPEAT, but it's unlikely to be necessary since the previous behavior only guaranteed that 1 << order pages would be reclaimed before failing for order > PAGE_ALLOC_COSTLY_ORDER. That reclaim is not guaranteed to be contiguous memory, so repeating for such large orders is usually not beneficial. Removing the setting of __GFP_RETRY_MAYFAIL to restore the previous behavior, specifically not allowing alloc_skb() to fail for small orders and oom kill if necessary rather than allowing RPCs to fail. Fixes: dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic") Signed-off-by: David Rientjes --- net/core/skbuff.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -5270,7 +5270,6 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len, unsigned long chunk; struct sk_buff *skb; struct page *page; - gfp_t gfp_head; int i; *errcode = -EMSGSIZE; @@ -5280,12 +5279,8 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len, if (npages > MAX_SKB_FRAGS) return NULL; - gfp_head = gfp_mask; - if (gfp_head & __GFP_DIRECT_RECLAIM) - gfp_head |= __GFP_RETRY_MAYFAIL; - *errcode = -ENOBUFS; - skb = alloc_skb(header_len, gfp_head); + skb = alloc_skb(header_len, gfp_mask); if (!skb) return NULL;