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
| ||
|
Date: Mon, 29 Feb 2016 07:58:44 -0800 From: Peter Hurley <peter@...leysoftware.com> To: Mike Galbraith <umgwanakikbuti@...il.com> Cc: Francois Romieu <romieu@...zoreil.com>, Eric Dumazet <edumazet@...gle.com>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>, dmaengine@...r.kernel.org, John Ogness <john.ogness@...utronix.de>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Andrew Morton <akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: Softirq priority inversion from "softirq: reduce latencies" On 02/29/2016 07:40 AM, Mike Galbraith wrote: > On Mon, 2016-02-29 at 07:03 -0800, Peter Hurley wrote: > >>> If I'm listening properly, the root cause is that there is a timing >>> constraint involved, which is being exposed because one softirq raises >>> another (ew). >> >> Not the case. The softirq is raised from interrupt. > > Yeah, saw that on re-read. > >> Before Eric's change, when an interrupt raises a new softirq >> while processing another softirq, the new softirq is immediately >> processed *after the existing softirq completes*. > > Not necessarily, Eric only changed it from an arbitrary count to an > arbitrary time, so your irq could just as well land when there's no > count left and be up the same creek. Your misreading the softirq abort logic: neither 2ms nor a fixed number of loops has elapsed. All that's happened is the first loop of NET_RX softirq has woken a process; that is sufficient to abort softirq and defer it for ksoftirqd. That's why I'm saying this is a priority inversion, and one that will happen a lot. > I was more infatuated by the constraint that's left dangling in the > breeze any time processing is deferred to ksoftirqd. > > -Mike >
Powered by blists - more mailing lists