linux-kernel - Re: [PATCH V7 4/4] softirq: Allow early break the softirq processing loop

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:   Tue, 13 Oct 2020 12:43:57 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Qais Yousef <qais.yousef@....com>
Cc:     jun qian <qianjun.kernel@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>, peterz@...radead.org,
        will@...nel.org, luto@...nel.org, linux-kernel@...r.kernel.org,
        Yafang Shao <laoar.shao@...il.com>,
        Uladzislau Rezki <urezki@...il.com>
Subject: Re: [PATCH V7 4/4] softirq: Allow early break the softirq processing
 loop

On Fri, Oct 09, 2020 at 04:01:39PM +0100, Qais Yousef wrote:
> On 09/29/20 13:44, Frederic Weisbecker wrote:
> > > that will delay the net_rx/tx softirq to process, Peter's branch
> > > maybe can slove
> > > the problem
> > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git core/softirq
> > 
> > It's probably also the right time for me to resume on this patchset:
> > 
> > https://lwn.net/Articles/779564/
> > 
> > In the long term this will allow us to have per vector threads that can be
> > individually triggered upon high loads, and even soft interruptible by
> > other vectors from irq_exit(). Also if several vectors are on high loads
> > at the same time, this leaves the balance decisions to the scheduler instead
> > of all these workarounds we scratch our heads on for several years now.
> > 
> > Besides, I'm convinced that splitting the softirqs is something we want in
> > the long run anyway.
> 
> So if I understood correctly we'll end up with a kthread for each softirq type
> that can be scheduled individually on any CPU following the 'normal' scheduler
> rules, correct?
> 
> If I got it right, I like that. I certainly think having these softirqs as RT
> threads (like irq threads) makes a lot more sense. At least one would be able
> to use priorities to reason about when it's okay to preempt them or not.
> 
> If I got it wrong, why we can't do that?

We can't do that right away because some softirq vectors may rely on the
fact that they can't be interrupted by other softirq vectors. If they use
per cpu data, they can perfectly assume that it's locally softirq-safe
and not use any lock to protect it, provided the data is stricly per-cpu
of course.

So we'll need to check all the softirq handlers and make sure they don't
do such assumption, or fix the site. I can imagine it as an iterative
pushdown just like we did with the big kernel lock.

Thanks.