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: <20201105140224.GK17076@casper.infradead.org>
Date:   Thu, 5 Nov 2020 14:02:24 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Eric Dumazet <erdnetdev@...il.com>
Cc:     linux-mm@...ck.org, netdev@...r.kernel.org,
        Dongli Zhang <dongli.zhang@...cle.com>,
        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 Thu, Nov 05, 2020 at 02:21:25PM +0100, Eric Dumazet wrote:
> 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 ?

Isn't this the commit which unmasks the problem, though?  I don't think
it's the buggy commit, but if your tree doesn't have 79930f5892e, then
you don't need this patch.

Or are you saying the problem dates back all the way to
c93bdd0e03e8 ("netvm: allow skb allocation to use PFMEMALLOC reserves")

> > +		if (nc->pfmemalloc) {
> 
>                 if (unlikely(nc->pfmemalloc)) {

ACK.  Will make the change once we've settled on an appropriate Fixes tag.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ