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:   Mon, 9 Nov 2020 14:32:49 +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:02:24PM +0000, Matthew Wilcox wrote:
> 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.

Which commit should I claim this fixes?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ