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]
Date:   Fri, 6 Jul 2018 07:39:42 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm,oom: Bring OOM notifier callbacks to outside of OOM
 killer.

On Tue 03-07-18 09:01:01, Paul E. McKenney wrote:
> On Tue, Jul 03, 2018 at 09:24:13AM +0200, Michal Hocko wrote:
> > On Mon 02-07-18 14:37:14, Paul E. McKenney wrote:
> > [...]
> > > commit d2b8d16b97ac2859919713b2d98b8a3ad22943a2
> > > Author: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > > Date:   Mon Jul 2 14:30:37 2018 -0700
> > > 
> > >     rcu: Remove OOM code
> > >     
> > >     There is reason to believe that RCU's OOM code isn't really helping
> > >     that much, given that the best it can hope to do is accelerate invoking
> > >     callbacks by a few seconds, and even then only if some CPUs have no
> > >     non-lazy callbacks, a condition that has been observed to be rare.
> > >     This commit therefore removes RCU's OOM code.  If this causes problems,
> > >     it can easily be reinserted.
> > >     
> > >     Reported-by: Michal Hocko <mhocko@...nel.org>
> > >     Reported-by: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
> > >     Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > 
> > I would also note that waiting in the notifier might be a problem on its
> > own because we are holding the oom_lock and the system cannot trigger
> > the OOM killer while we are holding it and waiting for oom_callback_wq
> > event. I am not familiar with the code to tell whether this can deadlock
> > but from a quick glance I _suspect_ that we might depend on __rcu_reclaim
> > and basically an arbitrary callback so no good.
> > 
> > Acked-by: Michal Hocko <mhocko@...e.com>
> > 
> > Thanks!
> 
> Like this?

Thanks!
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists