linux-kernel - Re: [PATCH 2/2] genirq: Resend nested irq's ancestor irq

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:	Thu, 14 Jun 2012 12:34:12 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ning Jiang <ning.n.jiang@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] genirq: Resend nested irq's ancestor irq

On Thu, 14 Jun 2012, Ning Jiang wrote:
> We'll set IRQS_PENDING for handle_nested_irq if it's disabled. When
> it's re-enabled later on, check_irq_resend() will detect this flag
> and trigger the software resend mechanism. resend_irqs() will call
> desc->handle_irq() directly to process this interrupt, hence the
> irq_nested_primary_handler() will be called for the nested irq which
> gives us a warning.
> 
> If we need to resend a nested interrupt, we have to trace all the
> way back to its ancestor and trigger ancestor's irq flow handler.

And what makes you believe that the ancestors demux handler will find
the irq bit of the nested interrupt still pending? There is NO
guarantee for that.

The correct solution for this is to replace the tasklet with a kernel
thread and check whether the interrupt is marked nested or not and
then invoke the correct function.

That requires a check for irq in progress in the nested handler as
well, but that's trivial to add.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/