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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83d68f28-cae7-012d-0f4b-82960b248bd8@suse.cz>
Date:   Thu, 5 Nov 2020 12:56:43 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
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,
        Jann Horn <jannh@...gle.com>
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")
> 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) {
> +			free_the_page(page, compound_order(page));
> +			goto refill;

Theoretically the refill can fail and we return NULL while leaving nc->va 
pointing to a freed page, so I think you should set nc->va to NULL.

Geez, can't the same thing already happen after we sub the nc->pagecnt_bias from 
page ref, and last users of the page fragments then return them and dec the ref 
to zero and the page gets freed?

> +		}
>   
>   #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