linux-kernel - Re: [RFC PATCH] mm/oom_kill: allow oom kill allocating task for non-global case

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: <YL+YFbiAsj77iqhq@dhcp22.suse.cz>
Date:   Tue, 8 Jun 2021 18:17:25 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Aaron Tomlin <atomlin@...hat.com>, Waiman Long <llong@...hat.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] mm/oom_kill: allow oom kill allocating task for
 non-global case

On Wed 09-06-21 00:22:13, Tetsuo Handa wrote:
> On 2021/06/08 22:58, Michal Hocko wrote:
> > I do not see this message to be ever printed on 4.18 for memcg oom:
> >         /* Found nothing?!?! Either we hang forever, or we panic. */
> >         if (!oc->chosen && !is_sysrq_oom(oc) && !is_memcg_oom(oc)) {
> >                 dump_header(oc, NULL);
> >                 panic("Out of memory and no killable processes...\n");
> >         }
> > 
> > So how come it got triggered here? Is it possible that there is a global
> > oom killer somehow going on along with the memcg OOM? Because the below
> > stack clearly points to a memcg OOM and a new one AFAICS.
> 
> 4.18 does print this message, and panic() will be called if global OOM
> killer invocation were in progress. 
> 
> 4.18.0-193.51.1.el8.x86_64 is doing
> 
> ----------
>         select_bad_process(oc);
>         /* Found nothing?!?! */
>         if (!oc->chosen) {
>                 dump_header(oc, NULL);
>                 pr_warn("Out of memory and no killable processes...\n");
>                 /*
>                  * If we got here due to an actual allocation at the
>                  * system level, we cannot survive this and will enter
>                  * an endless loop in the allocator. Bail out now.
>                  */
>                 if (!is_sysrq_oom(oc) && !is_memcg_oom(oc))
>                         panic("System is deadlocked on memory\n");
>         }
> ----------

Ahh, OK. That would explain that. I have looked at 4.18 Vanilla kernel.
I do not have RHEL sources handy and neither checked the 4.18 stable
tree. Thanks for the clarification!
 
[...]
> Since dump_tasks() from dump_header(oc, NULL) does not exclude tasks
> which already has MMF_OOM_SKIP set, it is possible that the last OOM
> killable victim was already OOM killed but the OOM reaper failed to reclaim
> memory and set MMF_OOM_SKIP. (Well, maybe we want to exclude (or annotate)
> MMF_OOM_SKIP tasks when showing OOM victim candidates...)

Well, the allocating task was clearly alive and whether it has been
reaped or not is not all that important as it should force the charge as
an oom victim. This is actually the most puzzling part. Because the
allocating task either is not a preexisting OOM victim and therefore
could become one or it has been and should have skipped the memcg killer
altogether. But I fail to see how it could be missed completely while
looking for a victim.
-- 
Michal Hocko
SUSE Labs