linux-kernel - Re: [RFC/RFT PATCH 1/2] sched/core: Check and schedule ksoftirq

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: <Y6BPLoHJNWjjMUv8@linutronix.de>
Date:   Mon, 19 Dec 2022 12:46:54 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Frederic Weisbecker <frederic@...nel.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        rafael@...nel.org, daniel.lezcano@...aro.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        len.brown@...el.com, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC/RFT PATCH 1/2] sched/core: Check and schedule ksoftirq

On 2022-12-19 12:33:22 [+0100], Peter Zijlstra wrote:
> ksoftirq is typically a CFS task while idle injection is required to be
> a FIFO (typically FIFO-1) task -- so that would require lifting
> ksoftirqd to FIFO and that has other problems.
> 
> I'm guessing the problem case is where idle injection comes in while
> ksoftirq is running (and preempted), because in that case you cannot run
> the softirq stuff in-place.
> 
> The 'right' thing to do would be to PI boost ksoftirqd in that case I
> suppose. Perhaps something like so, it would boost ksoftirq when it's
> running, and otherwise runs the ksoftirqd thing in-situ.
> 
> I've not really throught hard about this though, so perhaps I completely
> wrecked things.

I don't know why you intend to run ksoftirqd but in general it breaks RT
left and right and we attempt to avoid running ksoftirqd as much as
possible. If it runs and you go and boost it then it probably gets even
worse from RT point of view.

ksoftirqd runs softirqs from hardirq context. Everything else is handled
in is handled within local-bh-disable+enable loop. We already have have
the boost-ksoftird hammer which is the per-CPU BLK called
local_bh_disable(). In general everything should be moved out of it.
For timers we have the ktimerd thread which needs clean up. 

Sebastian