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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Mar 2020 19:04:44 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Michal Hocko <mhocko@...nel.org>,
        David Rientjes <rientjes@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>, 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/16 18:31, Michal Hocko wrote:
>> What happens if the allocator has SCHED_FIFO?
> 
> The same thing as a SCHED_FIFO running in a tight loop in the userspace.
> 
> As long as a high priority context depends on a resource held by a low
> priority task then we have a priority inversion problem and the page
> allocator is no real exception here. But I do not see the allocator
> is much different from any other code in the kernel. We do not add
> random sleeps here and there to push a high priority FIFO or RT tasks
> out of the execution context. We do cond_resched to help !PREEMPT
> kernels but priority related issues are really out of scope of that
> facility.
> 

Spinning with realtime priority in userspace is a userspace's bug.
Spinning with realtime priority in kernelspace until watchdog fires is
a kernel's bug. We are not responsible for userspace's bug, and I'm
asking whether the memory allocator kernel code can give enough CPU
time to other threads even if current thread has realtime priority.