linux-kernel - Re: [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom

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:   Mon, 12 Sep 2016 11:11:41 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     linux-mm@...ck.org, rientjes@...gle.com, hannes@...xchg.org,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        oleg@...hat.com, viro@...iv.linux.org.uk
Subject: Re: [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom_victim

On Sat 10-09-16 21:55:49, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > > > Do we want to thaw OOM victims from the beginning? If the freezer
> > > > depends on CONFIG_MMU=y , we don't need to thaw OOM victims.
> > > 
> > > We want to thaw them, at least at this stage, because the task might be
> > > sitting on a memory which is not reclaimable by the oom reaper (e.g.
> > > different buffers of file descriptors etc.).
> 
> I haven't heard an answer to the question whether the freezer depends on
> CONFIG_MMU=y. But I assume the answer is yes here.

I do not think it depends on CONFIG_MMU. At least CGROUP_FREEZER depends
on CONFIG_CGROUPS and that doesn't seem to have any direct dependency on
MMU.

> > 
> > If you worry about tasks which are sitting on a memory which is not
> > reclaimable by the oom reaper, why you don't worry about tasks which
> > share mm and do not share signal (i.e. clone(CLONE_VM && !CLONE_SIGHAND)
> > tasks) ? Thawing only tasks which share signal is a halfway job.
> > 
> 
> Here is a different approach which does not thaw tasks as of mark_oom_victim()
> but thaws tasks as of oom_killer_disable(). I think that we don't need to
> distinguish OOM victims and killed/exiting tasks when we disable the OOM
> killer, for trying to reclaim as much memory as possible is preferable for
> reducing the possibility of memory allocation failure after the OOM killer
> is disabled.

This makes the oom_killer_disable suspend specific which is imho not
necessary. While we do not have any other user outside of the suspend
path right now and I hope we will not need any in a foreseeable future
there is no real reason to do a hack like this if we can make the
implementation suspend independent.

> Compared to your approach
> 
> >  include/linux/sched.h |  2 +-
> >  kernel/exit.c         | 38 ++++++++++++++++++++++++++++----------
> >  kernel/freezer.c      |  3 ++-
> >  mm/oom_kill.c         | 29 +++++++++++++++++------------
> >  4 files changed, 48 insertions(+), 24 deletions(-)
> 
> , my approach does not touch exit logic.

I consider the exit path changes so miniscule that trading it with pm
specific code in the oom sounds like a worse solution. Well, all that
assuming that the actual change is correct, of course.

-- 
Michal Hocko
SUSE Labs