[patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD

[patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD

[Thomas Gleixner]

The following series marks the obvious interrupts IRQF_NO_THREAD to
prevent forced interrupt threading - no guarantee of completeness :)

The last patch enables the forced threading mechanism in the core
code, which in turn enables the "irqthreaded" commandline option.

Thanks,

	tglx

[patch 1/4] powerpc: 85xx: Mark cascade irq IRQF_NO_THREAD

[Thomas Gleixner]

Cascade interrupt must run in hard interrupt context.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/powerpc/platforms/85xx/mpc85xx_cds.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_cds.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -178,7 +178,7 @@ static irqreturn_t mpc85xx_8259_cascade_
 
 static struct irqaction mpc85xxcds_8259_irqaction = {
 	.handler = mpc85xx_8259_cascade_action,
-	.flags = IRQF_SHARED,
+	.flags = IRQF_SHARED | IRQF_NO_THREAD,
 	.name = "8259 cascade",
 };
 #endif /* PPC_I8259 */

[patch 2/4] powerpc: wsp: Mark opb cascade handler IRQF_NO_THREAD

[Thomas Gleixner]

Cascade handlers must run in hard interrupt context.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/powerpc/platforms/wsp/opb_pic.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/powerpc/platforms/wsp/opb_pic.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/wsp/opb_pic.c
+++ linux-2.6/arch/powerpc/platforms/wsp/opb_pic.c
@@ -320,7 +320,8 @@ void __init opb_pic_init(void)
 		}
 
 		/* Attach opb interrupt handler to new virtual IRQ */
-		rc = request_irq(virq, opb_irq_handler, 0, "OPB LS Cascade", opb);
+		rc = request_irq(virq, opb_irq_handler, IRQF_NO_THREAD,
+				 "OPB LS Cascade", opb);
 		if (rc) {
 			printk("opb: request_irq failed: %d\n", rc);
 			continue;

[patch 3/4] powerpc: Mark IPI interrupts IRQF_NO_THREAD

[Thomas Gleixner]

IPI handlers cannot be threaded. Remove the obsolete IRQF_DISABLED
flag (see commit e58aa3d2) while at it.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/powerpc/kernel/smp.c              |    2 +-
 arch/powerpc/platforms/powermac/smp.c  |    4 ++--
 arch/powerpc/sysdev/xics/xics-common.c |    6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6/arch/powerpc/kernel/smp.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6/arch/powerpc/kernel/smp.c
@@ -170,7 +170,7 @@ int smp_request_message_ipi(int virq, in
 		return 1;
 	}
 #endif
-	err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
+	err = request_irq(virq, smp_ipi_action[msg], IRQF_NO_THREAD|IRQF_PERCPU,
 			  smp_ipi_name[msg], 0);
 	WARN(err < 0, "unable to request_irq %d for %s (rc %d)\n",
 		virq, smp_ipi_name[msg], err);
Index: linux-2.6/arch/powerpc/platforms/powermac/smp.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/smp.c
+++ linux-2.6/arch/powerpc/platforms/powermac/smp.c
@@ -200,7 +200,7 @@ static int psurge_secondary_ipi_init(voi
 
 	if (psurge_secondary_virq)
 		rc = request_irq(psurge_secondary_virq, psurge_ipi_intr,
-			IRQF_DISABLED|IRQF_PERCPU, "IPI", NULL);
+			IRQF_NO_THREAD|IRQF_PERCPU, "IPI", NULL);
 
 	if (rc)
 		pr_err("Failed to setup secondary cpu IPI\n");
@@ -408,7 +408,7 @@ static int __init smp_psurge_kick_cpu(in
 
 static struct irqaction psurge_irqaction = {
 	.handler = psurge_ipi_intr,
-	.flags = IRQF_DISABLED|IRQF_PERCPU,
+	.flags = IRQF_NO_THREAD|IRQF_PERCPU,
 	.name = "primary IPI",
 };
 
Index: linux-2.6/arch/powerpc/sysdev/xics/xics-common.c
===================================================================
--- linux-2.6.orig/arch/powerpc/sysdev/xics/xics-common.c
+++ linux-2.6/arch/powerpc/sysdev/xics/xics-common.c
@@ -134,11 +134,11 @@ static void xics_request_ipi(void)
 	BUG_ON(ipi == NO_IRQ);
 
 	/*
-	 * IPIs are marked IRQF_DISABLED as they must run with irqs
-	 * disabled, and PERCPU.  The handler was set in map.
+	 * IPIs are marked PERCPU and also IRQF_NO_THREAD as they must
+	 * run in hard interrupt context. The handler was set in map.
 	 */
 	BUG_ON(request_irq(ipi, icp_ops->ipi_action,
-			   IRQF_DISABLED|IRQF_PERCPU, "IPI", NULL));
+			   IRQF_NO_THREAD|IRQF_PERCPU, "IPI", NULL));
 }
 
 int __init xics_smp_probe(void)

[patch 4/4] powerpc: Allow irq threading

[Thomas Gleixner]

All interrupts which must be non threaded are marked
IRQF_NO_THREAD. So it's safe to allow force threaded handlers.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/powerpc/Kconfig |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -132,6 +132,7 @@ config PPC
 	select IRQ_PER_CPU
 	select GENERIC_IRQ_SHOW
 	select GENERIC_IRQ_SHOW_LEVEL
+	select IRQ_FORCED_THREADING
 	select HAVE_RCU_TABLE_FREE if SMP
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_BPF_JIT if (PPC64 && NET)

Re: [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD

[Gabriel Paubert]

On Wed, Oct 05, 2011 at 12:30:49PM -0000, Thomas Gleixner wrote:
> The following series marks the obvious interrupts IRQF_NO_THREAD to
> prevent forced interrupt threading - no guarantee of completeness :)
> 
> The last patch enables the forced threading mechanism in the core
> code, which in turn enables the "irqthreaded" commandline option.

Is there any description of what "interrupt threading" means?

I'm only looking for a pointer to a web page, a mailing list thread
(I am no more subscribed to lkml, too many things to do, so maybe
it has been discussed but it comes out of the blue on linuxppc-dev), 
or a well commented git commit?

>From followups, I see that cascaded interrupt controller should
not be threaded. I suspect that the private VME bridge driver
(Universe chip) I maintain here will need it: clients request
a given VME interrupt (level/vector) and specify an interrupt
handler which is called by the handler for the PCI interrupt.

	Regards,
	Gabriel

Re: [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD

[Thomas Gleixner]

On Wed, 5 Oct 2011, Gabriel Paubert wrote:

> On Wed, Oct 05, 2011 at 12:30:49PM -0000, Thomas Gleixner wrote:
> > The following series marks the obvious interrupts IRQF_NO_THREAD to
> > prevent forced interrupt threading - no guarantee of completeness :)
> > 
> > The last patch enables the forced threading mechanism in the core
> > code, which in turn enables the "irqthreaded" commandline option.
> 
> Is there any description of what "interrupt threading" means?

That means that the interrupt handler is running in a thread. The
interrupt itself merily wakes the thread. That's a debugging option in
mainline - it comes handy when interrupt handlers crash as the system
just kills the thread, but stays otherwise alive. If the same
situation happens in the normal hard interrupt context, then it takes
them machine down completely.

Aside of that it's a prerequisite to support PREEMPT_RT on your
arch/machine.

> I'm only looking for a pointer to a web page, a mailing list thread

https://lwn.net/Articles/429690/

> (I am no more subscribed to lkml, too many things to do, so maybe
> it has been discussed but it comes out of the blue on linuxppc-dev), 
> or a well commented git commit?
> 
> >From followups, I see that cascaded interrupt controller should
> not be threaded. I suspect that the private VME bridge driver
> (Universe chip) I maintain here will need it: clients request
> a given VME interrupt (level/vector) and specify an interrupt
> handler which is called by the handler for the PCI interrupt.

Can't tell as I don't know how your code looks like. If your
subinterrupts are registered with the core interrupt system and the
drivers install their handlers via request_irq(), then yes. If you
just have your own registration and handling stuff (which you
shouldn't) then you might be better off to let the dispatch interrupt
handler be threaded so that all the demuxed ones run in that same
thread.

Thanks,

	tglx

Re: [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD

[Gabriel Paubert]

On Wed, Oct 05, 2011 at 05:31:48PM +0200, Thomas Gleixner wrote:
> On Wed, 5 Oct 2011, Gabriel Paubert wrote:
> 
> > On Wed, Oct 05, 2011 at 12:30:49PM -0000, Thomas Gleixner wrote:
> > > The following series marks the obvious interrupts IRQF_NO_THREAD to
> > > prevent forced interrupt threading - no guarantee of completeness :)
> > > 
> > > The last patch enables the forced threading mechanism in the core
> > > code, which in turn enables the "irqthreaded" commandline option.
> > 
> > Is there any description of what "interrupt threading" means?
> 
> That means that the interrupt handler is running in a thread. The
> interrupt itself merily wakes the thread. That's a debugging option in
> mainline - it comes handy when interrupt handlers crash as the system
> just kills the thread, but stays otherwise alive. If the same
> situation happens in the normal hard interrupt context, then it takes
> them machine down completely.
> 
> Aside of that it's a prerequisite to support PREEMPT_RT on your
> arch/machine.
> 
> > I'm only looking for a pointer to a web page, a mailing list thread
> 
> https://lwn.net/Articles/429690/

Thanks.

> 
> > (I am no more subscribed to lkml, too many things to do, so maybe
> > it has been discussed but it comes out of the blue on linuxppc-dev), 
> > or a well commented git commit?
> > 
> > >From followups, I see that cascaded interrupt controller should
> > not be threaded. I suspect that the private VME bridge driver
> > (Universe chip) I maintain here will need it: clients request
> > a given VME interrupt (level/vector) and specify an interrupt
> > handler which is called by the handler for the PCI interrupt.
> 
> Can't tell as I don't know how your code looks like. If your
> subinterrupts are registered with the core interrupt system and the
> drivers install their handlers via request_irq(), then yes. If you
> just have your own registration and handling stuff (which you
> shouldn't) then you might be better off to let the dispatch interrupt
> handler be threaded so that all the demuxed ones run in that same
> thread.


Well, for now I have my own registration, because when I originally wrote
the code (over a decade ago), there was no simple way to add potentially
~1800 additional interrupt sources (and the size of the interrupt descriptor
array on a machine with 16MB of RAM was not negligible, it became several
percent of the, minimalistic, kernel). 

This might be feasible now, but I still have boards with the first release 
of the bridge, which has very nasty interrupt related bugs (sometimes it 
incorrectly reports the level, only the vector is correct).

	Regards,	
	Gabriel