linux-kernel - Re: [patch v5] mm: lru_cache_disable: replace work queue synchronization with synchronize

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]

Message-ID: <YisJ5SLBijAbcwHD@linutronix.de>
Date:   Fri, 11 Mar 2022 09:35:49 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Marcelo Tosatti <mtosatti@...hat.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Minchan Kim <minchan@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Nicolas Saenz Julienne <nsaenzju@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: [patch v5] mm: lru_cache_disable: replace work queue
 synchronization with synchronize_rcu

+ sched division

On 2022-03-10 18:23:26 [-0800], Andrew Morton wrote:
> On Thu, 10 Mar 2022 10:22:12 -0300 Marcelo Tosatti <mtosatti@...hat.com> wrote:
> > On systems that run FIFO:1 applications that busy loop,
> > any SCHED_OTHER task that attempts to execute
> > on such a CPU (such as work threads) will not
> > be scheduled, which leads to system hangs.
…
> 
> Permitting a realtime thread to hang the entire system warrants a
> -stable backport, I think.  That's just rude.

I'm not sure if someone is not willingly breaking the system. Based on
my experience, a thread with an elevated priority (that FIFO, RR or DL)
should not hog the CPU. A normal user (!root && !CAP_SYS_NICE) can't
increase the priority of the task.
To avoid a system hangup there is sched_rt_runtime_us which ensures that
all RT threads are throttled once the RT class exceed a certain amount
of runtime. This has been relaxed a little on systems with more CPUs so
that the RT runtime can be shared but this sharing (RT_RUNTIME_SHARE)
has been disabled by default a while ago. That safe switch
(sched_rt_runtime_us) can be disabled and is usually disabled on RT
system since the RT tasks usually run longer especially in corner cases.

People often isolate CPUs and have busy-loop tasks running with
SCHED_OTHER given that there is nothing else going on there will be no
preemption. In this case, the worker would preempt the task.
In this scenario I _can_ understand that one wants to avoid that
preemption and try things differently like this patch suggests. We can
even offload RCU thread from isolated CPUs.
But I wouldn't say this requires a backport because there is way for a
RT thread, that claims 100% of the CPU, to break the system.

Sebastian