linux-kernel - Re: [PATCH] memcg, oom: move out_of

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: <20180629072132.GA13860@dhcp22.suse.cz>
Date:   Fri, 29 Jun 2018 09:21:32 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Greg Thelen <gthelen@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Shakeel Butt <shakeelb@...gle.com>, linux-mm@...ck.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] memcg, oom: move out_of_memory back to the charge path

On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> Michal Hocko <mhocko@...nel.org> wrote:
[...]
> > +	if (mem_cgroup_out_of_memory(memcg, mask, order))
> > +		return OOM_SUCCESS;
> > +
> > +	WARN(1,"Memory cgroup charge failed because of no reclaimable memory! "
> > +		"This looks like a misconfiguration or a kernel bug.");
> 
> I'm not sure here if the warning should here or so strongly worded.  It
> seems like the current task could be oom reaped with MMF_OOM_SKIP and
> thus mem_cgroup_out_of_memory() will return false.  So there's nothing
> alarming in that case.

If the task is reaped then its charges should be released as well and
that means that we should get below the limit. Sure there is some room
for races but this should be still unlikely. Maybe I am just
underestimating though.

What would you suggest instead?
-- 
Michal Hocko
SUSE Labs