linux-kernel - Re: [PATCH,RESEND] softirq: Introduce SOFTIRQ_FORCED

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:   Sat, 28 Aug 2021 00:27:34 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Wang Qing <wangqing@...o.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Wang Qing <wangqing@...o.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Will Deacon <will@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Dirk Behme <dirk.behme@...bosch.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH,RESEND] softirq: Introduce SOFTIRQ_FORCED_THREADING

Wang,

On Mon, Aug 23 2021 at 11:33, Wang Qing wrote:

> At present, whether the softirq is executed when the interrupt exits 
> is controlled by IRQ_FORCED_THREADING. This is unreasonable. It should 
> be split and allowed to take effect separately.

There is nothing unreasonable about it. When interrupt force threading
is in effect then it obviously requires that soft interrupt processing
goes into threaded mode as well. But the threaded execution still takes
place when the force threaded interrupt handler completes. Only softirqs
which are raised from hard interrupt context (e.g. timer interrupt) are
forced off to ksoftirqd.

What you are proposing here is completly different as you enforce
softirq execution in context of ksoftirqd only.

> At the same time, we should increase the priority of ksoftirqd when
> forbidden to execute in interrupt exits. I refer to the implementation 
> of PREEMPT_RT and think it is reasonable.

What are you referring to? PREEMPT_RT does not modify the priority of
ksoftirqd. If system designers want to do that, then they can do so from
user space. 

And doing so can be problematic depending on the workload as this
effectively breaks the softirq overload mitigation mechanism which
depends on deferring to ksoftirqd so that e.g. the consumers of received
network packets can be scheduled and the system can make progress.

Just because it does not break on your system with your particular
workload and configuration does not make it suitable for general
consumption.

> +#ifdef CONFIG_SOFTIRQ_FORCED_THREADING
> +static inline void invoke_softirq(void)
> +{
> +	wakeup_softirqd();

Depending on the configuration and timing this breaks any early boot
mechanism which depends on softirqs being handled before ksoftirqd is
available. This was clearly never tested with full RCU debugging
enabled. 

Aside of that the changelog lacks any form of technical analysis and
justification for this. Just claiming that things are [un]reasonable and
making uninformed statements about PREEMPT_RT does not qualify. Quite
the contrary it's definitely unreasonable.

Thanks,

        tglx