linux-kernel - Re: Nested IRQs resend

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>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1806222245490.1589@nanos.tec.linutronix.de>
Date:   Fri, 22 Jun 2018 23:07:02 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Sodagudi Prasad <psodagud@...eaurora.org>
cc:     linux-kernel@...r.kernel.org
Subject: Re: Nested IRQs resend

On Sat, 19 May 2018, Sodagudi Prasad wrote:
> 
> Trying to use IRQ resend support with simple driver. I observed that,
> re-triggering of nested threaded IRQs is not working. After digging into
> "kernel/irq/resend.c" file more,
> parent IRQ is needed for re-trigger to work.  I could not get much details,
> why parent_irq is needed for threaded IRQs resend?

The whole resend stuff was written way before threaded irqs or even nested
threaded irqs existed at all.

> 1)	Could you please provide more details about resend of nested threaded
> IRQs ?
> 2)	What should be the parent_irq handler in the case of nested IRQs ?
> threaded IRQ ?
> 3)	Are you expecting that parent_irq handler should know pending nesting
> IRQs  for resend?

Well, the point is that a nested threaded irq runs in the context of some
other irq. Ignore the parent irq concept in the resend code as that is
completely misleading. That's a corner case which has nothing to do with
nested threading at all.

Lets look at how nested threaded irqs work. The thread in which they nest
is usually a demultiplexing interrupt of some sort, which looks at a status
register to figure out which sub interrupt is pending and then executes
that interrupt in its own context. The reason why this is done is because
the whole handling of the underlying irq chip needs threaded context and
synchronization so running everything from the demultiplex thread makes a
lot of things simpler.

But there is no established relationship between the nested irq and the
demultiplex irq at least not from the nested irqs point of view. And even
if you'd know the irq number of the demultiplex irq and you could resend
it, then still you need a way to tell it that you want your particular
nested one resent in its context.

The proper solution to this is to actually implement the irq_retrigger()
callback for the underlying irq chip. That callback then has to set a
software maintained 'pending' bit for the interrupt in question and
retrigger the demultiplex interrupt. That works because the irq chip has
been populated by the facility which also requested the demultiplex
interrupt so the relationship is known there or can be made known
easily. Note, that in that case it's not even strictly required to use the
resend mechanism for the demultiplex interrupt. The irq chip providing
facilty knows that this is a nested thread case so it can simply wake the
demultiplex thread via irq_wake_thread().

Hope that helps. If you have further questions, don't hesitate to ask.

Thanks,

	tglx