lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 5 Nov 2020 14:21:25 +0100
From:   Eric Dumazet <erdnetdev@...il.com>
To:     "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        linux-mm@...ck.org, netdev@...r.kernel.org,
        Dongli Zhang <dongli.zhang@...cle.com>
Cc:     Aruna Ramakrishna <aruna.ramakrishna@...cle.com>,
        Bert Barbe <bert.barbe@...cle.com>,
        Rama Nichanamatlu <rama.nichanamatlu@...cle.com>,
        Venkat Venkatsubra <venkat.x.venkatsubra@...cle.com>,
        Manjunath Patil <manjunath.b.patil@...cle.com>,
        Joe Jin <joe.jin@...cle.com>,
        SRINIVAS <srinivas.eeda@...cle.com>, stable@...r.kernel.org
Subject: Re: [PATCH] page_frag: Recover from memory pressure



On 11/5/20 5:21 AM, Matthew Wilcox (Oracle) wrote:
> When the machine is under extreme memory pressure, the page_frag allocator
> signals this to the networking stack by marking allocations with the
> 'pfmemalloc' flag, which causes non-essential packets to be dropped.
> Unfortunately, even after the machine recovers from the low memory
> condition, the page continues to be used by the page_frag allocator,
> so all allocations from this page will continue to be dropped.
> 
> Fix this by freeing and re-allocating the page instead of recycling it.
> 
> Reported-by: Dongli Zhang <dongli.zhang@...cle.com>
> Cc: Aruna Ramakrishna <aruna.ramakrishna@...cle.com>
> Cc: Bert Barbe <bert.barbe@...cle.com>
> Cc: Rama Nichanamatlu <rama.nichanamatlu@...cle.com>
> Cc: Venkat Venkatsubra <venkat.x.venkatsubra@...cle.com>
> Cc: Manjunath Patil <manjunath.b.patil@...cle.com>
> Cc: Joe Jin <joe.jin@...cle.com>
> Cc: SRINIVAS <srinivas.eeda@...cle.com>
> Cc: stable@...r.kernel.org
> Fixes: 79930f5892e ("net: do not deplete pfmemalloc reserve")

Your patch looks fine, although this Fixes: tag seems incorrect.

79930f5892e ("net: do not deplete pfmemalloc reserve") was propagating
the page pfmemalloc status into the skb, and seems correct to me.

The bug was the page_frag_alloc() was keeping a problematic page for
an arbitrary period of time ?

> Signed-off-by: Matthew Wilcox (Oracle) <willy@...radead.org>
> ---
>  mm/page_alloc.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 778e815130a6..631546ae1c53 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5139,6 +5139,10 @@ void *page_frag_alloc(struct page_frag_cache *nc,
>  
>  		if (!page_ref_sub_and_test(page, nc->pagecnt_bias))
>  			goto refill;
> +		if (nc->pfmemalloc) {

                if (unlikely(nc->pfmemalloc)) {

> +			free_the_page(page, compound_order(page));
> +			goto refill;
> +		}
>  
>  #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
>  		/* if size can vary use size else just use PAGE_SIZE */
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ