Date: Thu, 14 Jun 2012 12:34:12 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Ning Jiang <ning.n.jiang@gmail.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] genirq: Resend nested irq's ancestor irq
In-Reply-To: <1339662697-4600-2-git-send-email-ning.n.jiang@gmail.com>
Message-ID: <alpine.LFD.2.02.1206141221360.3086@ionos>
References: <1339662697-4600-1-git-send-email-ning.n.jiang@gmail.com> <1339662697-4600-2-git-send-email-ning.n.jiang@gmail.com>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1234
Lines: 30

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/