From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:42939 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753549AbbD2KLS (ORCPT ); Wed, 29 Apr 2015 06:11:18 -0400 Subject: Patch "net: do not deplete pfmemalloc reserve" has been added to the 3.14-stable tree To: edumazet@google.com, davem@davemloft.net, gregkh@linuxfoundation.org Cc: , From: Date: Wed, 29 Apr 2015 12:11:06 +0200 Message-ID: <1430302266247207@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled net: do not deplete pfmemalloc reserve to the 3.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: net-do-not-deplete-pfmemalloc-reserve.patch and it can be found in the queue-3.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From foo@baz Wed Apr 29 12:00:35 CEST 2015 From: Eric Dumazet Date: Wed, 22 Apr 2015 07:33:36 -0700 Subject: net: do not deplete pfmemalloc reserve From: Eric Dumazet [ Upstream commit 79930f5892e134c6da1254389577fffb8bd72c66 ] build_skb() should look at the page pfmemalloc status. If set, this means page allocator allocated this page in the expectation it would help to free other pages. Networking stack can do that only if skb->pfmemalloc is also set. Also, we must refrain using high order pages from the pfmemalloc reserve, so __page_frag_refill() must also use __GFP_NOMEMALLOC for them. Under memory pressure, using order-0 pages is probably the best strategy. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/core/skbuff.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -309,7 +309,11 @@ struct sk_buff *build_skb(void *data, un memset(skb, 0, offsetof(struct sk_buff, tail)); skb->truesize = SKB_TRUESIZE(size); - skb->head_frag = frag_size != 0; + if (frag_size) { + skb->head_frag = 1; + if (virt_to_head_page(data)->pfmemalloc) + skb->pfmemalloc = 1; + } atomic_set(&skb->users, 1); skb->head = data; skb->data = data; @@ -352,7 +356,8 @@ refill: gfp_t gfp = gfp_mask; if (order) - gfp |= __GFP_COMP | __GFP_NOWARN; + gfp |= __GFP_COMP | __GFP_NOWARN | + __GFP_NOMEMALLOC; nc->frag.page = alloc_pages(gfp, order); if (likely(nc->frag.page)) break; Patches currently in stable-queue which might be from edumazet@google.com are queue-3.14/net-fix-crash-in-build_skb.patch queue-3.14/tcp-avoid-looping-in-tcp_send_fin.patch queue-3.14/net-do-not-deplete-pfmemalloc-reserve.patch queue-3.14/tcp-fix-possible-deadlock-in-tcp_send_fin.patch