linux-kernel - Re: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems

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:   Sat, 14 Mar 2020 08:15:32 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     David Rientjes <rientjes@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Michal Hocko <mhocko@...nel.org>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems

On 2020/03/14 7:01, David Rientjes wrote:
> The entire issue is that the victim never gets a chance to run because the 
> allocator doesn't give it a chance to run on an UP system.  Your patch is 
> broken because if the victim is current, you've lost your golden 
> opportunity to actually exit and ceded control to the allocator that will 
> now starve the victim.
> 

I still cannot understand. There is no need to give CPU time to OOM victims.
We just need to give CPU time to the OOM reaper kernel thread till the OOM
reaper kernel thread sets MMF_OOM_SKIP to OOM victims. If current thread is
an OOM victim, schedule_timeout_killable(1) will give other threads (including
the OOM reaper kernel thread) CPU time to run. That is similar with your
cond_resched() patch (except that cond_resched() might fail to give other
threads CPU time to run if current thread has realtime priority), isn't it?

So, please explain the mechanism why cond_resched() works but
schedule_timeout_killable(1) cannot work.