[I-pipe][PATCH v2 0/4] ipipe: x86: Fix IRQ migrations, avoid confusing kernel messages

[I-pipe][PATCH v2 0/4] ipipe: x86: Fix IRQ migrations, avoid confusing kernel messages

[Florian Bezdeka]

Hi,

this are the results from an internal debugging session. We we're facing 
some problems related to system tunings and some confusing kernel
messages related to spurious IRQs.

The most important part:
IRQ migrations were broken in 4.19 and 5.4 based branches 

Patch 1 is compile tested only.

Changes to v1:
  - Add Patch 1, "Backport" for ipipe 4.4 branch
  - Add Patch 3, Fix IRQ migrations for 5.4
  - Add Patch 4, Fix IRQ migrations for 4.19

Best regards,
Florian

Florian Bezdeka (3):
  [4.4]       ipipe: x86: Do not call BUG() in case of retriggered APIC 
              vectors
  [4.19, 5.4] ipipe: x86: Suppress unexpected trap warning for racing APIC 
              vectors
  [5.4]       ipipe: x86: Fix IRQ migrations, pending migrations were
              never handled
  [4.19]      ipipe: x86: Fix IRQ migrations, pending migrations were
              never handled
-- 
2.30.2

[I-pipe 4.4] [PATCH v2 1/4] ipipe: x86: Do not call BUG() in case of retriggered APIC vectors

[Florian Bezdeka]

The CPU hotplugging code might re-trigger a vector. In that case the
vector is in the VECTOR_RETRIGGERED state. With this patch applied ipipe
does no longer call BUG() for such vectors.

This is a backport from the 4.19 and 5.4 ipipe branches handling the
VECTOR_SHUTDOWN state. The VECTOR_SHUTDOWN case itself does not exist in
4.4, but the VECTOR_RETRIGGERED case does.

__ipipe_handle_irq() is now synchronized with do_IRQ().

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 arch/x86/kernel/ipipe.c | 44 +++++++++++++++++++++++++++++++----------
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c
index 739b5c37ec7b..6020739256f9 100644
--- a/arch/x86/kernel/ipipe.c
+++ b/arch/x86/kernel/ipipe.c
@@ -33,6 +33,7 @@
 #include <linux/mm.h>
 #include <linux/kgdb.h>
 #include <linux/ipipe_tickdev.h>
+#include <linux/ratelimit.h>
 #include <asm/asm-offsets.h>
 #include <asm/unistd.h>
 #include <asm/processor.h>
@@ -428,22 +429,44 @@ skip_kgdb:
 	return 0;
 }
 
+static inline int __ipipe_irq_from_vector(int vector, int *irq)
+{
+	struct irq_desc *desc;
+
+	if (vector >= FIRST_SYSTEM_VECTOR) {
+		*irq = ipipe_apic_vector_irq(vector);
+		return 0;
+	}
+
+	desc = __this_cpu_read(vector_irq[vector]);
+	if (likely(!IS_ERR_OR_NULL(desc))) {
+		*irq = irq_desc_get_irq(desc);
+		return 0;
+	}
+
+#ifdef CONFIG_X86_LOCAL_APIC
+	__ack_APIC_irq();
+#endif
+
+	if (desc == VECTOR_UNUSED) {
+		pr_emerg_ratelimited("%s: %d.%d Unexpected IRQ trap\n",
+				     __func__, smp_processor_id(), vector);
+	} else {
+		__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
+	}
+
+	return -1;
+}
+
 int __ipipe_handle_irq(struct pt_regs *regs)
 {
 	struct ipipe_percpu_data *p = __ipipe_raw_cpu_ptr(&ipipe_percpu);
 	int irq, vector = regs->orig_ax, flags = 0;
 	struct pt_regs *tick_regs;
-	struct irq_desc *desc;
 
 	if (likely(vector < 0)) {
-		vector = ~vector;
-		if (vector >= FIRST_SYSTEM_VECTOR)
-			irq = ipipe_apic_vector_irq(vector);
-		else {
-			desc = __this_cpu_read(vector_irq[vector]);
-			BUG_ON(IS_ERR_OR_NULL(desc));
-			irq = irq_desc_get_irq(desc);
-		}
+		if (__ipipe_irq_from_vector(~vector, &irq) < 0)
+			goto out;
 	} else { /* Software-generated. */
 		irq = vector;
 		flags = IPIPE_IRQF_NOACK;
@@ -477,7 +500,8 @@ int __ipipe_handle_irq(struct pt_regs *regs)
 		__ipipe_call_mayday(regs);
 
 	ipipe_trace_irqend(irq, regs);
-	
+
+out:
 	if (!__ipipe_root_p ||
 	    test_bit(IPIPE_STALL_FLAG, &__ipipe_root_status))
 		return 0;
-- 
2.30.2

[I-pipe 4.19, 5.4] [PATCH v2 2/4] ipipe: x86: Suppress unexpected trap warning for racing APIC vectors

[Florian Bezdeka]

It might happen that the APIC vector in flight has already been shut
down by the device driver. In such a race it's still an unexpected
trap, but nothing we should warn about. Checking the vector error
state upfront avoids confusion.

This is what do_IRQ() would do as well, in a slightly simplified way.
Both code paths are synchronized now, including the printk rate
limiting.

Re-setting the vector to the VECTOR_UNUSED state helps to detect
spurious interrupts in case the vector is re-triggered several times.

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 arch/x86/kernel/ipipe.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c
index 81e0889a8298..63c6dc683ed3 100644
--- a/arch/x86/kernel/ipipe.c
+++ b/arch/x86/kernel/ipipe.c
@@ -471,7 +471,14 @@ static inline int __ipipe_irq_from_vector(int vector, int *irq)
 #ifdef CONFIG_X86_LOCAL_APIC
 	__ack_APIC_irq();
 #endif
-	pr_err("unexpected IRQ trap at vector %#x\n", vector);
+
+	if (desc == VECTOR_UNUSED) {
+		pr_emerg_ratelimited("%s: %d.%d Unexpected IRQ trap\n",
+				     __func__, smp_processor_id(), vector);
+	} else {
+		__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
+	}
+
 	return -1;
 }
 
-- 
2.30.2

[I-pipe 5.4] [PATCH v2 3/4] ipipe: x86: Fix IRQ migrations, pending migrations were never handled

[Florian Bezdeka]

IRQ migrations did not work. Writing a new IRQ SMP affinity into
/proc/irq/<irq>/smp_affinity had no effect.

It turned out that the pending migration was never handled. With
commit d4637fc8663b ("x86/ipipe: fix chained irq handling") do_IRQ() is
bypassed because it is not able to deal with chained IRQs and
generic_handle_irq_desc() is directly called instead.

The bypass forgot to take care about pending IRQ migrations. As
do_IRQ() is no longer used when ipipe is enabled, we can restore it to
the Linux version and move the call of __ipipe_move_root_irq() to
__ipipe_do_IRQ(). With that change applied the first part of the IRQ
migration is working again. IRQs arrive at the new target CPU.

The second part of the IRQ migration (cleanup of the old vector at the
previous target CPU) was broken because __ipipe_do_IRQ() injects the
registers from the last timer tick, so apicd->vector is always -1.
Removing the vector == apicd->vector check allows triggering the
cleanup IPI. This part is now synchronized with Linux >= 5.8.

Fixes: d4637fc8663b ("x86/ipipe: fix chained irq handling")

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 arch/x86/kernel/apic/vector.c |  8 +++++++-
 arch/x86/kernel/irq.c         |  3 +--
 arch/x86/kernel/irq_64.c      | 10 +++++-----
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index a744b78eaa94..32889c2ef4a1 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -949,7 +949,13 @@ static void __irq_complete_move(struct irq_cfg *cfg, unsigned vector)
 	if (likely(!apicd->move_in_progress))
 		return;
 
-	if (vector == apicd->vector && apicd->cpu == smp_processor_id())
+	/*
+	 * If the interrupt arrived on the new target CPU, cleanup the
+	 * vector on the old target CPU. A vector check is not required
+	 * because an interrupt can never move from one vector to another
+	 * on the same CPU.
+	 */
+	if (apicd->cpu == smp_processor_id())
 		__send_cleanup_vector(apicd);
 }
 
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index f946bc4387e4..7077388e4f1c 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -237,13 +237,12 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
 	/* high bit used in ret_from_ code  */
 	unsigned vector = ~regs->orig_ax;
 
-	desc = __this_cpu_read(vector_irq[vector]);
-	__ipipe_move_root_irq(desc);
 	entering_irq();
 
 	/* entering_irq() tells RCU that we're not quiescent.  Check it. */
 	RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
 
+	desc = __this_cpu_read(vector_irq[vector]);
 	if (likely(!IS_ERR_OR_NULL(desc))) {
 		if (IS_ENABLED(CONFIG_X86_32))
 			handle_irq(desc, regs);
diff --git a/arch/x86/kernel/irq_64.c b/arch/x86/kernel/irq_64.c
index b998d982cb4a..16ea3c5aed6d 100644
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -76,20 +76,20 @@ int irq_init_percpu_irqstack(unsigned int cpu)
 void __ipipe_do_IRQ(unsigned int irq, void *cookie)
 {
 	struct pt_regs *regs = raw_cpu_ptr(&ipipe_percpu.tick_regs);
+	struct irq_desc *desc = irq_to_desc(irq);
 	struct pt_regs *old_regs = set_irq_regs(regs);
 	unsigned int (*handler)(struct pt_regs *regs);
-	struct irq_desc *desc;
 
 	handler = (typeof(handler))cookie;
 
+	__ipipe_move_root_irq(desc);
+
 	entering_irq();
 
-	if (handler == do_IRQ) {
-		desc = irq_to_desc(irq);
+	if (handler == do_IRQ)
 		generic_handle_irq_desc(desc);
-	} else {
+	else
 		handler(regs);
-	}
 
 	exiting_irq();
 
-- 
2.30.2

[I-pipe 4.19] [PATCH v2 4/4] ipipe: x86: Fix IRQ migrations, pending migrations were never handled

[Florian Bezdeka]

IRQ migrations did not work. Writing a new IRQ SMP affinity into
/proc/irq/<irq>/smp_affinity had no effect.

It turned out that the pending migration was never handled. With
commit 2ecf1d517b02 ("x86/ipipe: fix chained irq handling") do_IRQ() is
bypassed because it is not able to deal with chained IRQs and
generic_handle_irq_desc() is directly called instead.

The bypass forgot to take care about pending IRQ migrations. As
do_IRQ() is no longer used when ipipe is enabled, we can restore it to
the Linux version and move the call of __ipipe_move_root_irq() to
__ipipe_do_IRQ(). With that change applied the first part of the IRQ
migration is working again. IRQs arrive at the new target CPU.

The second part of the IRQ migration (cleanup of the old vector at the
previous target CPU) was broken because __ipipe_do_IRQ() injects the
registers from the last timer tick, so apicd->vector is always -1.
Removing the vector == apicd->vector check allows triggering the
cleanup IPI. This part is now synchronized with Linux >= 5.8.

Fixes: 2ecf1d517b02 ("x86/ipipe: fix chained irq handling")

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 arch/x86/kernel/apic/vector.c |  8 +++++++-
 arch/x86/kernel/irq.c         |  4 +---
 arch/x86/kernel/irq_64.c      | 10 +++++-----
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index e6be44dce5b4..a6017d0d14b6 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -951,7 +951,13 @@ static void __irq_complete_move(struct irq_cfg *cfg, unsigned vector)
 	if (likely(!apicd->move_in_progress))
 		return;
 
-	if (vector == apicd->vector && apicd->cpu == smp_processor_id())
+	/*
+	 * If the interrupt arrived on the new target CPU, cleanup the
+	 * vector on the old target CPU. A vector check is not required
+	 * because an interrupt can never move from one vector to another
+	 * on the same CPU.
+	 */
+	if (apicd->cpu == smp_processor_id())
 		__send_cleanup_vector(apicd);
 }
 
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 251171c77bd6..455d64178bcd 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -236,14 +236,12 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
 	/* high bit used in ret_from_ code  */
 	unsigned vector = ~regs->orig_ax;
 
-	desc = __this_cpu_read(vector_irq[vector]);
-	__ipipe_move_root_irq(desc);
 	entering_irq();
 
 	/* entering_irq() tells RCU that we're not quiescent.  Check it. */
 	RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
 
-
+	desc = __this_cpu_read(vector_irq[vector]);
 	if (!handle_irq(desc, regs)) {
 		ack_APIC_irq();
 
diff --git a/arch/x86/kernel/irq_64.c b/arch/x86/kernel/irq_64.c
index 7fc8ad19940c..7bcdd6ee9441 100644
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -95,22 +95,22 @@ bool handle_irq(struct irq_desc *desc, struct pt_regs *regs)
 void __ipipe_do_IRQ(unsigned int irq, void *cookie)
 {
 	struct pt_regs *regs = raw_cpu_ptr(&ipipe_percpu.tick_regs);
+	struct irq_desc *desc = irq_to_desc(irq);
 	struct pt_regs *old_regs = set_irq_regs(regs);
 	unsigned int (*handler)(struct pt_regs *regs);
-	struct irq_desc *desc;
 
 	handler = (typeof(handler))cookie;
 
+	__ipipe_move_root_irq(desc);
+
 	entering_irq();
 
 	stack_overflow_check(regs);
 
-	if (handler == do_IRQ) {
-		desc = irq_to_desc(irq);
+	if (handler == do_IRQ)
 		generic_handle_irq_desc(desc);
-	} else {
+	else
 		handler(regs);
-	}
 
 	exiting_irq();
 
-- 
2.35.1

Re: [I-pipe 4.4] [PATCH v2 1/4] ipipe: x86: Do not call BUG() in case of retriggered APIC vectors

[Jan Kiszka]

On 01.03.22 13:52, Florian Bezdeka wrote:
> The CPU hotplugging code might re-trigger a vector. In that case the
> vector is in the VECTOR_RETRIGGERED state. With this patch applied ipipe
> does no longer call BUG() for such vectors.
> 

Doesn't this also avoids a BUG for spurious vectors (provided they can
exist for other reasons than CPU offlining)?

> This is a backport from the 4.19 and 5.4 ipipe branches handling the
> VECTOR_SHUTDOWN state. The VECTOR_SHUTDOWN case itself does not exist in
> 4.4, but the VECTOR_RETRIGGERED case does.
> 
> __ipipe_handle_irq() is now synchronized with do_IRQ().
> 
> Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
> ---
>  arch/x86/kernel/ipipe.c | 44 +++++++++++++++++++++++++++++++----------
>  1 file changed, 34 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c
> index 739b5c37ec7b..6020739256f9 100644
> --- a/arch/x86/kernel/ipipe.c
> +++ b/arch/x86/kernel/ipipe.c
> @@ -33,6 +33,7 @@
>  #include <linux/mm.h>
>  #include <linux/kgdb.h>
>  #include <linux/ipipe_tickdev.h>
> +#include <linux/ratelimit.h>
>  #include <asm/asm-offsets.h>
>  #include <asm/unistd.h>
>  #include <asm/processor.h>
> @@ -428,22 +429,44 @@ skip_kgdb:
>  	return 0;
>  }
>  
> +static inline int __ipipe_irq_from_vector(int vector, int *irq)
> +{
> +	struct irq_desc *desc;
> +
> +	if (vector >= FIRST_SYSTEM_VECTOR) {
> +		*irq = ipipe_apic_vector_irq(vector);
> +		return 0;
> +	}
> +
> +	desc = __this_cpu_read(vector_irq[vector]);
> +	if (likely(!IS_ERR_OR_NULL(desc))) {
> +		*irq = irq_desc_get_irq(desc);
> +		return 0;
> +	}
> +
> +#ifdef CONFIG_X86_LOCAL_APIC
> +	__ack_APIC_irq();
> +#endif
> +
> +	if (desc == VECTOR_UNUSED) {
> +		pr_emerg_ratelimited("%s: %d.%d Unexpected IRQ trap\n",
> +				     __func__, smp_processor_id(), vector);
> +	} else {
> +		__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
> +	}
> +
> +	return -1;
> +}
> +
>  int __ipipe_handle_irq(struct pt_regs *regs)
>  {
>  	struct ipipe_percpu_data *p = __ipipe_raw_cpu_ptr(&ipipe_percpu);
>  	int irq, vector = regs->orig_ax, flags = 0;
>  	struct pt_regs *tick_regs;
> -	struct irq_desc *desc;
>  
>  	if (likely(vector < 0)) {
> -		vector = ~vector;
> -		if (vector >= FIRST_SYSTEM_VECTOR)
> -			irq = ipipe_apic_vector_irq(vector);
> -		else {
> -			desc = __this_cpu_read(vector_irq[vector]);
> -			BUG_ON(IS_ERR_OR_NULL(desc));
> -			irq = irq_desc_get_irq(desc);
> -		}
> +		if (__ipipe_irq_from_vector(~vector, &irq) < 0)
> +			goto out;
>  	} else { /* Software-generated. */
>  		irq = vector;
>  		flags = IPIPE_IRQF_NOACK;
> @@ -477,7 +500,8 @@ int __ipipe_handle_irq(struct pt_regs *regs)
>  		__ipipe_call_mayday(regs);
>  
>  	ipipe_trace_irqend(irq, regs);
> -	
> +
> +out:
>  	if (!__ipipe_root_p ||
>  	    test_bit(IPIPE_STALL_FLAG, &__ipipe_root_status))
>  		return 0;

Thanks, applied.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [I-pipe][PATCH v2 0/4] ipipe: x86: Fix IRQ migrations, avoid confusing kernel messages

[Jan Kiszka]

On 01.03.22 13:52, Florian Bezdeka wrote:
> Hi,
> 
> this are the results from an internal debugging session. We we're facing 
> some problems related to system tunings and some confusing kernel
> messages related to spurious IRQs.
> 
> The most important part:
> IRQ migrations were broken in 4.19 and 5.4 based branches 
> 
> Patch 1 is compile tested only.
> 
> Changes to v1:
>   - Add Patch 1, "Backport" for ipipe 4.4 branch
>   - Add Patch 3, Fix IRQ migrations for 5.4
>   - Add Patch 4, Fix IRQ migrations for 4.19
> 
> Best regards,
> Florian
> 
> Florian Bezdeka (3):
>   [4.4]       ipipe: x86: Do not call BUG() in case of retriggered APIC 
>               vectors
>   [4.19, 5.4] ipipe: x86: Suppress unexpected trap warning for racing APIC 
>               vectors
>   [5.4]       ipipe: x86: Fix IRQ migrations, pending migrations were
>               never handled
>   [4.19]      ipipe: x86: Fix IRQ migrations, pending migrations were
>               never handled

Thanks for these non-trivial fixes! All applied now, CI running.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [I-pipe 4.4] [PATCH v2 1/4] ipipe: x86: Do not call BUG() in case of retriggered APIC vectors

[Florian Bezdeka]

On 01.03.22 21:21, Jan Kiszka wrote:
> On 01.03.22 13:52, Florian Bezdeka wrote:
>> The CPU hotplugging code might re-trigger a vector. In that case the
>> vector is in the VECTOR_RETRIGGERED state. With this patch applied ipipe
>> does no longer call BUG() for such vectors.
>>
> 
> Doesn't this also avoids a BUG for spurious vectors (provided they can
> exist for other reasons than CPU offlining)?

Yes it does. Forgot to mention that...

> 
>> This is a backport from the 4.19 and 5.4 ipipe branches handling the
>> VECTOR_SHUTDOWN state. The VECTOR_SHUTDOWN case itself does not exist in
>> 4.4, but the VECTOR_RETRIGGERED case does.
>>
>> __ipipe_handle_irq() is now synchronized with do_IRQ().
>>
>> Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
>> ---
>>  arch/x86/kernel/ipipe.c | 44 +++++++++++++++++++++++++++++++----------
>>  1 file changed, 34 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c
>> index 739b5c37ec7b..6020739256f9 100644
>> --- a/arch/x86/kernel/ipipe.c
>> +++ b/arch/x86/kernel/ipipe.c
>> @@ -33,6 +33,7 @@
>>  #include <linux/mm.h>
>>  #include <linux/kgdb.h>
>>  #include <linux/ipipe_tickdev.h>
>> +#include <linux/ratelimit.h>
>>  #include <asm/asm-offsets.h>
>>  #include <asm/unistd.h>
>>  #include <asm/processor.h>
>> @@ -428,22 +429,44 @@ skip_kgdb:
>>  	return 0;
>>  }
>>  
>> +static inline int __ipipe_irq_from_vector(int vector, int *irq)
>> +{
>> +	struct irq_desc *desc;
>> +
>> +	if (vector >= FIRST_SYSTEM_VECTOR) {
>> +		*irq = ipipe_apic_vector_irq(vector);
>> +		return 0;
>> +	}
>> +
>> +	desc = __this_cpu_read(vector_irq[vector]);
>> +	if (likely(!IS_ERR_OR_NULL(desc))) {
>> +		*irq = irq_desc_get_irq(desc);
>> +		return 0;
>> +	}
>> +
>> +#ifdef CONFIG_X86_LOCAL_APIC
>> +	__ack_APIC_irq();
>> +#endif
>> +
>> +	if (desc == VECTOR_UNUSED) {
>> +		pr_emerg_ratelimited("%s: %d.%d Unexpected IRQ trap\n",
>> +				     __func__, smp_processor_id(), vector);
>> +	} else {
>> +		__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
>> +	}
>> +
>> +	return -1;
>> +}
>> +
>>  int __ipipe_handle_irq(struct pt_regs *regs)
>>  {
>>  	struct ipipe_percpu_data *p = __ipipe_raw_cpu_ptr(&ipipe_percpu);
>>  	int irq, vector = regs->orig_ax, flags = 0;
>>  	struct pt_regs *tick_regs;
>> -	struct irq_desc *desc;
>>  
>>  	if (likely(vector < 0)) {
>> -		vector = ~vector;
>> -		if (vector >= FIRST_SYSTEM_VECTOR)
>> -			irq = ipipe_apic_vector_irq(vector);
>> -		else {
>> -			desc = __this_cpu_read(vector_irq[vector]);
>> -			BUG_ON(IS_ERR_OR_NULL(desc));
>> -			irq = irq_desc_get_irq(desc);
>> -		}
>> +		if (__ipipe_irq_from_vector(~vector, &irq) < 0)
>> +			goto out;
>>  	} else { /* Software-generated. */
>>  		irq = vector;
>>  		flags = IPIPE_IRQF_NOACK;
>> @@ -477,7 +500,8 @@ int __ipipe_handle_irq(struct pt_regs *regs)
>>  		__ipipe_call_mayday(regs);
>>  
>>  	ipipe_trace_irqend(irq, regs);
>> -	
>> +
>> +out:
>>  	if (!__ipipe_root_p ||
>>  	    test_bit(IPIPE_STALL_FLAG, &__ipipe_root_status))
>>  		return 0;
> 
> Thanks, applied.
> 
> Jan
>