[PATCH] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock

[PATCH] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock

[linz]

Hi, I find a call trace when I use v6.6.y-dovetail + xenomai v3.3 branch, the call trace is as follows

[    1.510903] IRQ pipeline: some code running in oob context 'Xenomai'
                             called an in-band only routine
[    1.510912] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S                 6.6.63-dovetail2 #8
[    1.510918] Hardware name: Pe2204 DEMO DDR4 (DT)
[    1.510920] IRQ stage: Xenomai
[    1.510923] Call trace:
[    1.510926]  dump_backtrace+0x90/0xe4
[    1.510940]  show_stack+0x14/0x1c
[    1.510946]  dump_stack_lvl+0x84/0xc8
[    1.510953]  dump_stack+0x14/0x1c
[    1.510957]  check_inband_stage+0xb0/0xc8
[    1.510965]  inband_irq_save+0xc/0x28
[    1.510971]  _raw_spin_lock_irqsave+0x14/0x90
[    1.510977]  its_send_single_command+0x24/0x154
[    1.510984]  lpi_update_config+0x9c/0x144
[    1.510990]  its_mask_irq+0x2c/0x64
[    1.510997]  irq_chip_mask_parent+0x18/0x20
[    1.511005]  its_mask_msi_irq+0x1c/0x28
[    1.511012]  handle_fasteoi_irq+0x1cc/0x2b4
[    1.511016]  generic_pipeline_irq_desc+0x6c/0xa4
[    1.511021]  generic_handle_domain_irq+0x18/0x20
[    1.511028]  gic_handle_irq+0x4c/0x120
[    1.511032]  handle_irq_pipelined+0x40/0x64
[    1.511038]  call_on_irq_stack+0x24/0x30
[    1.511044]  do_interrupt_handler+0x138/0x158
[    1.511050]  el1_interrupt+0x40/0x110
[    1.511055]  el1h_64_irq_handler+0x14/0x1c
[    1.511061]  el1h_64_irq+0x64/0x68
[    1.511064]  default_idle_call+0x30/0x78
[    1.511071]  do_idle+0x128/0x150
[    1.511077]  cpu_startup_entry+0x34/0x38
[    1.511081]  kernel_init+0x0/0x1d4
[    1.511088]  arch_post_acpi_subsys_init+0x0/0x8
[    1.511096]  start_kernel+0x504/0x5cc
[    1.511103]  __primary_switched+0xbc/0xc4


The function call causing the issue is as follows:
generic_handle_domain_irq
    => generic_pipeline_irq_desc
        => generic_handle_irq_desc
            => handle_fasteoi_irq
                => mask_cond_eoi_irq
                    => mask_irq
                        => its_mask_msi_irq
                            => irq_chip_mask_parent
                                => its_mask_irq
                                    => lpi_update_config
                                        => its_send_inv
                                            => BUILD_SINGLE_CMD_FUNC
                                                => raw_spin_lock_irqsave(&its->lock, flags);


On Dovetail-enabled kernels with Xenomai IRQ pipeline, GICv3 ITS interrupt handling runs in OOB (out-of-band) interrupt context. The original raw_spinlock_t used for its_node->lock invokes the standard in-band-only raw_spin_lock_irqsave() interface.
This triggers the following pipeline context violation warning: IRQ pipeline: some code running in oob context 'Xenomai' called an in-band only routine

raw_spin_lock_irqsave() is an in-band exclusive API and cannot be safely called from Xenomai OOB interrupt context, which violates the IRQ pipeline isolation rules.

I think that fix this by replacing raw_spinlock_t with hybrid_spinlock_t for the ITS node lock. The hybrid spinlock supports both in-band Linux kernel context and OOB Xenomai pipeline context, adapting lock/irqsave logic dynamically according to the running context, eliminating the context mismatch warning while guaranteeing lock mutual exclusion.

The fixed up patch is as follows:

From 1037fcf6d75ecf37e1caf283d1198177e7410be3 Mon Sep 17 00:00:00 2001
From: zhanglin <powertree@163.com>
Date: Thu, 25 Jun 2026 16:56:31 +0800
Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
 lock warning for ITS lock

---
 drivers/irqchip/irq-gic-v3-its.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0e57735eac..847b008b71 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -94,7 +94,7 @@ struct its_device;
  * list.
  */
 struct its_node {
-    raw_spinlock_t        lock;
+    hybrid_spinlock_t     lock;
     struct mutex        dev_alloc_lock;
     struct list_head    entry;
     void __iomem        *base;
-- 
2.34.1

Please help to review it, thank you.

Re: [PATCH] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock

[Jan Kiszka]

On 25.06.26 11:32, linz wrote:
> Hi, I find a call trace when I use v6.6.y-dovetail + xenomai v3.3 branch, the call trace is as follows
> 
> [    1.510903] IRQ pipeline: some code running in oob context 'Xenomai'
>                              called an in-band only routine
> [    1.510912] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S                 6.6.63-dovetail2 #8
> [    1.510918] Hardware name: Pe2204 DEMO DDR4 (DT)
> [    1.510920] IRQ stage: Xenomai
> [    1.510923] Call trace:
> [    1.510926]  dump_backtrace+0x90/0xe4
> [    1.510940]  show_stack+0x14/0x1c
> [    1.510946]  dump_stack_lvl+0x84/0xc8
> [    1.510953]  dump_stack+0x14/0x1c
> [    1.510957]  check_inband_stage+0xb0/0xc8
> [    1.510965]  inband_irq_save+0xc/0x28
> [    1.510971]  _raw_spin_lock_irqsave+0x14/0x90
> [    1.510977]  its_send_single_command+0x24/0x154
> [    1.510984]  lpi_update_config+0x9c/0x144
> [    1.510990]  its_mask_irq+0x2c/0x64
> [    1.510997]  irq_chip_mask_parent+0x18/0x20
> [    1.511005]  its_mask_msi_irq+0x1c/0x28
> [    1.511012]  handle_fasteoi_irq+0x1cc/0x2b4
> [    1.511016]  generic_pipeline_irq_desc+0x6c/0xa4
> [    1.511021]  generic_handle_domain_irq+0x18/0x20
> [    1.511028]  gic_handle_irq+0x4c/0x120
> [    1.511032]  handle_irq_pipelined+0x40/0x64
> [    1.511038]  call_on_irq_stack+0x24/0x30
> [    1.511044]  do_interrupt_handler+0x138/0x158
> [    1.511050]  el1_interrupt+0x40/0x110
> [    1.511055]  el1h_64_irq_handler+0x14/0x1c
> [    1.511061]  el1h_64_irq+0x64/0x68
> [    1.511064]  default_idle_call+0x30/0x78
> [    1.511071]  do_idle+0x128/0x150
> [    1.511077]  cpu_startup_entry+0x34/0x38
> [    1.511081]  kernel_init+0x0/0x1d4
> [    1.511088]  arch_post_acpi_subsys_init+0x0/0x8
> [    1.511096]  start_kernel+0x504/0x5cc
> [    1.511103]  __primary_switched+0xbc/0xc4
> 
> 
> The function call causing the issue is as follows:
> generic_handle_domain_irq
>     => generic_pipeline_irq_desc
>         => generic_handle_irq_desc
>             => handle_fasteoi_irq
>                 => mask_cond_eoi_irq
>                     => mask_irq
>                         => its_mask_msi_irq
>                             => irq_chip_mask_parent
>                                 => its_mask_irq
>                                     => lpi_update_config
>                                         => its_send_inv
>                                             => BUILD_SINGLE_CMD_FUNC
>                                                 => raw_spin_lock_irqsave(&its->lock, flags);
> 
> 
> On Dovetail-enabled kernels with Xenomai IRQ pipeline, GICv3 ITS interrupt handling runs in OOB (out-of-band) interrupt context. The original raw_spinlock_t used for its_node->lock invokes the standard in-band-only raw_spin_lock_irqsave() interface.
> This triggers the following pipeline context violation warning: IRQ pipeline: some code running in oob context 'Xenomai' called an in-band only routine
> 
> raw_spin_lock_irqsave() is an in-band exclusive API and cannot be safely called from Xenomai OOB interrupt context, which violates the IRQ pipeline isolation rules.
> 
> I think that fix this by replacing raw_spinlock_t with hybrid_spinlock_t for the ITS node lock. The hybrid spinlock supports both in-band Linux kernel context and OOB Xenomai pipeline context, adapting lock/irqsave logic dynamically according to the running context, eliminating the context mismatch warning while guaranteeing lock mutual exclusion.
> 
> The fixed up patch is as follows:
> 
> From 1037fcf6d75ecf37e1caf283d1198177e7410be3 Mon Sep 17 00:00:00 2001
> From: zhanglin <powertree@163.com>
> Date: Thu, 25 Jun 2026 16:56:31 +0800
> Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
>  lock warning for ITS lock
> 
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 0e57735eac..847b008b71 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -94,7 +94,7 @@ struct its_device;
>   * list.
>   */
>  struct its_node {
> -    raw_spinlock_t        lock;
> +    hybrid_spinlock_t     lock;
>      struct mutex        dev_alloc_lock;
>      struct list_head    entry;
>      void __iomem        *base;
> -- 
> 2.34.1
> 
> Please help to review it, thank you.

Thanks for reporting.

Philippe, Florian, any comments on this?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock

[Florian Bezdeka]

On Fri, 2026-07-10 at 12:12 +0200, Jan Kiszka wrote:
> On 25.06.26 11:32, linz wrote:
> > Hi, I find a call trace when I use v6.6.y-dovetail + xenomai v3.3 branch, the call trace is as follows
> > 
> > [    1.510903] IRQ pipeline: some code running in oob context 'Xenomai'
> >                              called an in-band only routine
> > [    1.510912] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S                 6.6.63-dovetail2 #8
> > [    1.510918] Hardware name: Pe2204 DEMO DDR4 (DT)
> > [    1.510920] IRQ stage: Xenomai
> > [    1.510923] Call trace:
> > [    1.510926]  dump_backtrace+0x90/0xe4
> > [    1.510940]  show_stack+0x14/0x1c
> > [    1.510946]  dump_stack_lvl+0x84/0xc8
> > [    1.510953]  dump_stack+0x14/0x1c
> > [    1.510957]  check_inband_stage+0xb0/0xc8
> > [    1.510965]  inband_irq_save+0xc/0x28
> > [    1.510971]  _raw_spin_lock_irqsave+0x14/0x90
> > [    1.510977]  its_send_single_command+0x24/0x154
> > [    1.510984]  lpi_update_config+0x9c/0x144
> > [    1.510990]  its_mask_irq+0x2c/0x64
> > [    1.510997]  irq_chip_mask_parent+0x18/0x20
> > [    1.511005]  its_mask_msi_irq+0x1c/0x28
> > [    1.511012]  handle_fasteoi_irq+0x1cc/0x2b4
> > [    1.511016]  generic_pipeline_irq_desc+0x6c/0xa4
> > [    1.511021]  generic_handle_domain_irq+0x18/0x20
> > [    1.511028]  gic_handle_irq+0x4c/0x120
> > [    1.511032]  handle_irq_pipelined+0x40/0x64
> > [    1.511038]  call_on_irq_stack+0x24/0x30
> > [    1.511044]  do_interrupt_handler+0x138/0x158
> > [    1.511050]  el1_interrupt+0x40/0x110
> > [    1.511055]  el1h_64_irq_handler+0x14/0x1c
> > [    1.511061]  el1h_64_irq+0x64/0x68
> > [    1.511064]  default_idle_call+0x30/0x78
> > [    1.511071]  do_idle+0x128/0x150
> > [    1.511077]  cpu_startup_entry+0x34/0x38
> > [    1.511081]  kernel_init+0x0/0x1d4
> > [    1.511088]  arch_post_acpi_subsys_init+0x0/0x8
> > [    1.511096]  start_kernel+0x504/0x5cc
> > [    1.511103]  __primary_switched+0xbc/0xc4
> > 
> > 
> > The function call causing the issue is as follows:
> > generic_handle_domain_irq
> >     => generic_pipeline_irq_desc
> >         => generic_handle_irq_desc
> >             => handle_fasteoi_irq
> >                 => mask_cond_eoi_irq
> >                     => mask_irq
> >                         => its_mask_msi_irq
> >                             => irq_chip_mask_parent
> >                                 => its_mask_irq
> >                                     => lpi_update_config
> >                                         => its_send_inv
> >                                             => BUILD_SINGLE_CMD_FUNC
> >                                                 => raw_spin_lock_irqsave(&its->lock, flags);
> > 
> > 
> > On Dovetail-enabled kernels with Xenomai IRQ pipeline, GICv3 ITS interrupt handling runs in OOB (out-of-band) interrupt context. The original raw_spinlock_t used for its_node->lock invokes the standard in-band-only raw_spin_lock_irqsave() interface.
> > This triggers the following pipeline context violation warning: IRQ pipeline: some code running in oob context 'Xenomai' called an in-band only routine
> > 
> > raw_spin_lock_irqsave() is an in-band exclusive API and cannot be safely called from Xenomai OOB interrupt context, which violates the IRQ pipeline isolation rules.
> > 
> > I think that fix this by replacing raw_spinlock_t with hybrid_spinlock_t for the ITS node lock. The hybrid spinlock supports both in-band Linux kernel context and OOB Xenomai pipeline context, adapting lock/irqsave logic dynamically according to the running context, eliminating the context mismatch warning while guaranteeing lock mutual exclusion.
> > 
> > The fixed up patch is as follows:
> > 
> > From 1037fcf6d75ecf37e1caf283d1198177e7410be3 Mon Sep 17 00:00:00 2001
> > From: zhanglin <powertree@163.com>
> > Date: Thu, 25 Jun 2026 16:56:31 +0800
> > Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
> >  lock warning for ITS lock
> > 
> > ---
> >  drivers/irqchip/irq-gic-v3-its.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> > index 0e57735eac..847b008b71 100644
> > --- a/drivers/irqchip/irq-gic-v3-its.c
> > +++ b/drivers/irqchip/irq-gic-v3-its.c
> > @@ -94,7 +94,7 @@ struct its_device;
> >   * list.
> >   */
> >  struct its_node {
> > -    raw_spinlock_t        lock;
> > +    hybrid_spinlock_t     lock;
> >      struct mutex        dev_alloc_lock;
> >      struct list_head    entry;
> >      void __iomem        *base;
> > -- 
> > 2.34.1
> > 
> > Please help to review it, thank you.
> 
> Thanks for reporting.
> 
> Philippe, Florian, any comments on this?
> 
> Jan

hybrid_spinlock_t doesn't look right at first glance, it's use should be
limited to struct irq_desc and IRQ chips. I would have expected
hard_spinlock_t, but I might miss something.

Assuming the gic-v3 IRQ chip is already marked / flagged as
IRQCHIP_PIPELINE_SAFE, right?

Florian

Re:Re: [PATCH] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock

[linz]

At 2026-07-10 18:59:08, "Florian Bezdeka" <florian.bezdeka@siemens.com> wrote:
>On Fri, 2026-07-10 at 12:12 +0200, Jan Kiszka wrote:
>> On 25.06.26 11:32, linz wrote:
>> > Hi, I find a call trace when I use v6.6.y-dovetail + xenomai v3.3 branch, the call trace is as follows
>> > 
>> > [    1.510903] IRQ pipeline: some code running in oob context 'Xenomai'
>> >                              called an in-band only routine
>> > [    1.510912] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S                 6.6.63-dovetail2 #8
>> > [    1.510918] Hardware name: Pe2204 DEMO DDR4 (DT)
>> > [    1.510920] IRQ stage: Xenomai
>> > [    1.510923] Call trace:
>> > [    1.510926]  dump_backtrace+0x90/0xe4
>> > [    1.510940]  show_stack+0x14/0x1c
>> > [    1.510946]  dump_stack_lvl+0x84/0xc8
>> > [    1.510953]  dump_stack+0x14/0x1c
>> > [    1.510957]  check_inband_stage+0xb0/0xc8
>> > [    1.510965]  inband_irq_save+0xc/0x28
>> > [    1.510971]  _raw_spin_lock_irqsave+0x14/0x90
>> > [    1.510977]  its_send_single_command+0x24/0x154
>> > [    1.510984]  lpi_update_config+0x9c/0x144
>> > [    1.510990]  its_mask_irq+0x2c/0x64
>> > [    1.510997]  irq_chip_mask_parent+0x18/0x20
>> > [    1.511005]  its_mask_msi_irq+0x1c/0x28
>> > [    1.511012]  handle_fasteoi_irq+0x1cc/0x2b4
>> > [    1.511016]  generic_pipeline_irq_desc+0x6c/0xa4
>> > [    1.511021]  generic_handle_domain_irq+0x18/0x20
>> > [    1.511028]  gic_handle_irq+0x4c/0x120
>> > [    1.511032]  handle_irq_pipelined+0x40/0x64
>> > [    1.511038]  call_on_irq_stack+0x24/0x30
>> > [    1.511044]  do_interrupt_handler+0x138/0x158
>> > [    1.511050]  el1_interrupt+0x40/0x110
>> > [    1.511055]  el1h_64_irq_handler+0x14/0x1c
>> > [    1.511061]  el1h_64_irq+0x64/0x68
>> > [    1.511064]  default_idle_call+0x30/0x78
>> > [    1.511071]  do_idle+0x128/0x150
>> > [    1.511077]  cpu_startup_entry+0x34/0x38
>> > [    1.511081]  kernel_init+0x0/0x1d4
>> > [    1.511088]  arch_post_acpi_subsys_init+0x0/0x8
>> > [    1.511096]  start_kernel+0x504/0x5cc
>> > [    1.511103]  __primary_switched+0xbc/0xc4
>> > 
>> > 
>> > The function call causing the issue is as follows:
>> > generic_handle_domain_irq
>> >     => generic_pipeline_irq_desc
>> >         => generic_handle_irq_desc
>> >             => handle_fasteoi_irq
>> >                 => mask_cond_eoi_irq
>> >                     => mask_irq
>> >                         => its_mask_msi_irq
>> >                             => irq_chip_mask_parent
>> >                                 => its_mask_irq
>> >                                     => lpi_update_config
>> >                                         => its_send_inv
>> >                                             => BUILD_SINGLE_CMD_FUNC
>> >                                                 => raw_spin_lock_irqsave(&its->lock, flags);
>> > 
>> > 
>> > On Dovetail-enabled kernels with Xenomai IRQ pipeline, GICv3 ITS interrupt handling runs in OOB (out-of-band) interrupt context. The original raw_spinlock_t used for its_node->lock invokes the standard in-band-only raw_spin_lock_irqsave() interface.
>> > This triggers the following pipeline context violation warning: IRQ pipeline: some code running in oob context 'Xenomai' called an in-band only routine
>> > 
>> > raw_spin_lock_irqsave() is an in-band exclusive API and cannot be safely called from Xenomai OOB interrupt context, which violates the IRQ pipeline isolation rules.
>> > 
>> > I think that fix this by replacing raw_spinlock_t with hybrid_spinlock_t for the ITS node lock. The hybrid spinlock supports both in-band Linux kernel context and OOB Xenomai pipeline context, adapting lock/irqsave logic dynamically according to the running context, eliminating the context mismatch warning while guaranteeing lock mutual exclusion.
>> > 
>> > The fixed up patch is as follows:
>> > 
>> > From 1037fcf6d75ecf37e1caf283d1198177e7410be3 Mon Sep 17 00:00:00 2001
>> > From: zhanglin <powertree@163.com>
>> > Date: Thu, 25 Jun 2026 16:56:31 +0800
>> > Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
>> >  lock warning for ITS lock
>> > 
>> > ---
>> >  drivers/irqchip/irq-gic-v3-its.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> > index 0e57735eac..847b008b71 100644
>> > --- a/drivers/irqchip/irq-gic-v3-its.c
>> > +++ b/drivers/irqchip/irq-gic-v3-its.c
>> > @@ -94,7 +94,7 @@ struct its_device;
>> >   * list.
>> >   */
>> >  struct its_node {
>> > -    raw_spinlock_t        lock;
>> > +    hybrid_spinlock_t     lock;
>> >      struct mutex        dev_alloc_lock;
>> >      struct list_head    entry;
>> >      void __iomem        *base;
>> > -- 
>> > 2.34.1
>> > 
>> > Please help to review it, thank you.
>> 
>> Thanks for reporting.
>> 
>> Philippe, Florian, any comments on this?
>> 
>> Jan
>
>hybrid_spinlock_t doesn't look right at first glance, it's use should be
>limited to struct irq_desc and IRQ chips. I would have expected
>hard_spinlock_t, but I might miss something.
>
>Assuming the gic-v3 IRQ chip is already marked / flagged as
>IRQCHIP_PIPELINE_SAFE, right?
>
>Florian

>


Thank you for your feedback

The gic-v3 IRQ chip is already marked with IRQCHIP_PIPELINE_SAFE. 
The its_irq_chip is not marked with IRQCHIP_PIPELINE_SAFE. I added the flag and tested, but it did not have any effect.

Meanwhile, I read the code related to IRQCHIP_PIPELINE_SAFE. If the gic-v3 IRQ chip is not marked with IRQCHIP_PIPELINE_SAFE, a call trace like the following would be reported:
MSI domain irqchip XXX is not pipeline-safe! or irqchip XXX is not pipeline-safe!
However, I did not see any such message in dmsg logs.

Based on Florian's suggestion, I revisited the Xenomai 4 documentation regarding hybrid_spinlock_t and hard_spinlock_t. 
I agree with Florian's point that hybrid_spinlock_t should be limited to struct irq_desc and IRQ chips, and that hard_spinlock_t is more appropriate for the ITS node lock.

I changed the lock to hard_spinlock_t and tested it. The call trace no longer appears and the system works fine.

The patch is as follows. Please help review it:

From e0cbc9316af331bf007c86e1fcab0ef8699b05c9 Mon Sep 17 00:00:00 2001
From: zhanglin1040 <zhanglin1040@phytium.com.cn>
Date: Mon, 13 Jul 2026 17:53:44 +0800
Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
 lock warning for ITS lock using hard spinlocks instead of hybrid spinlocks

---
 drivers/irqchip/irq-gic-v3-its.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0e57735eac..3f2b02b8f4 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -94,7 +94,7 @@ struct its_device;
  * list.
  */
 struct its_node {
-    raw_spinlock_t        lock;
+    hard_spinlock_t        lock;
     struct mutex        dev_alloc_lock;
     struct list_head    entry;
     void __iomem        *base;
-- 
2.34.1

Re: [PATCH] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock

[Jan Kiszka]

On 13.07.26 12:20, linz wrote:
> 
> At 2026-07-10 18:59:08, "Florian Bezdeka" <florian.bezdeka@siemens.com> wrote:
>> On Fri, 2026-07-10 at 12:12 +0200, Jan Kiszka wrote:
>>> On 25.06.26 11:32, linz wrote:
>>>> Hi, I find a call trace when I use v6.6.y-dovetail + xenomai v3.3 branch, the call trace is as follows
>>>>
>>>> [    1.510903] IRQ pipeline: some code running in oob context 'Xenomai'
>>>>                              called an in-band only routine
>>>> [    1.510912] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S                 6.6.63-dovetail2 #8
>>>> [    1.510918] Hardware name: Pe2204 DEMO DDR4 (DT)
>>>> [    1.510920] IRQ stage: Xenomai
>>>> [    1.510923] Call trace:
>>>> [    1.510926]  dump_backtrace+0x90/0xe4
>>>> [    1.510940]  show_stack+0x14/0x1c
>>>> [    1.510946]  dump_stack_lvl+0x84/0xc8
>>>> [    1.510953]  dump_stack+0x14/0x1c
>>>> [    1.510957]  check_inband_stage+0xb0/0xc8
>>>> [    1.510965]  inband_irq_save+0xc/0x28
>>>> [    1.510971]  _raw_spin_lock_irqsave+0x14/0x90
>>>> [    1.510977]  its_send_single_command+0x24/0x154
>>>> [    1.510984]  lpi_update_config+0x9c/0x144
>>>> [    1.510990]  its_mask_irq+0x2c/0x64
>>>> [    1.510997]  irq_chip_mask_parent+0x18/0x20
>>>> [    1.511005]  its_mask_msi_irq+0x1c/0x28
>>>> [    1.511012]  handle_fasteoi_irq+0x1cc/0x2b4
>>>> [    1.511016]  generic_pipeline_irq_desc+0x6c/0xa4
>>>> [    1.511021]  generic_handle_domain_irq+0x18/0x20
>>>> [    1.511028]  gic_handle_irq+0x4c/0x120
>>>> [    1.511032]  handle_irq_pipelined+0x40/0x64
>>>> [    1.511038]  call_on_irq_stack+0x24/0x30
>>>> [    1.511044]  do_interrupt_handler+0x138/0x158
>>>> [    1.511050]  el1_interrupt+0x40/0x110
>>>> [    1.511055]  el1h_64_irq_handler+0x14/0x1c
>>>> [    1.511061]  el1h_64_irq+0x64/0x68
>>>> [    1.511064]  default_idle_call+0x30/0x78
>>>> [    1.511071]  do_idle+0x128/0x150
>>>> [    1.511077]  cpu_startup_entry+0x34/0x38
>>>> [    1.511081]  kernel_init+0x0/0x1d4
>>>> [    1.511088]  arch_post_acpi_subsys_init+0x0/0x8
>>>> [    1.511096]  start_kernel+0x504/0x5cc
>>>> [    1.511103]  __primary_switched+0xbc/0xc4
>>>>
>>>>
>>>> The function call causing the issue is as follows:
>>>> generic_handle_domain_irq
>>>>     => generic_pipeline_irq_desc
>>>>         => generic_handle_irq_desc
>>>>             => handle_fasteoi_irq
>>>>                 => mask_cond_eoi_irq
>>>>                     => mask_irq
>>>>                         => its_mask_msi_irq
>>>>                             => irq_chip_mask_parent
>>>>                                 => its_mask_irq
>>>>                                     => lpi_update_config
>>>>                                         => its_send_inv
>>>>                                             => BUILD_SINGLE_CMD_FUNC
>>>>                                                 => raw_spin_lock_irqsave(&its->lock, flags);
>>>>
>>>>
>>>> On Dovetail-enabled kernels with Xenomai IRQ pipeline, GICv3 ITS interrupt handling runs in OOB (out-of-band) interrupt context. The original raw_spinlock_t used for its_node->lock invokes the standard in-band-only raw_spin_lock_irqsave() interface.
>>>> This triggers the following pipeline context violation warning: IRQ pipeline: some code running in oob context 'Xenomai' called an in-band only routine
>>>>
>>>> raw_spin_lock_irqsave() is an in-band exclusive API and cannot be safely called from Xenomai OOB interrupt context, which violates the IRQ pipeline isolation rules.
>>>>
>>>> I think that fix this by replacing raw_spinlock_t with hybrid_spinlock_t for the ITS node lock. The hybrid spinlock supports both in-band Linux kernel context and OOB Xenomai pipeline context, adapting lock/irqsave logic dynamically according to the running context, eliminating the context mismatch warning while guaranteeing lock mutual exclusion.
>>>>
>>>> The fixed up patch is as follows:
>>>>
>>>> From 1037fcf6d75ecf37e1caf283d1198177e7410be3 Mon Sep 17 00:00:00 2001
>>>> From: zhanglin <powertree@163.com>
>>>> Date: Thu, 25 Jun 2026 16:56:31 +0800
>>>> Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
>>>>  lock warning for ITS lock
>>>>
>>>> ---
>>>>  drivers/irqchip/irq-gic-v3-its.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>>> index 0e57735eac..847b008b71 100644
>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>> @@ -94,7 +94,7 @@ struct its_device;
>>>>   * list.
>>>>   */
>>>>  struct its_node {
>>>> -    raw_spinlock_t        lock;
>>>> +    hybrid_spinlock_t     lock;
>>>>      struct mutex        dev_alloc_lock;
>>>>      struct list_head    entry;
>>>>      void __iomem        *base;
>>>> -- 
>>>> 2.34.1
>>>>
>>>> Please help to review it, thank you.
>>>
>>> Thanks for reporting.
>>>
>>> Philippe, Florian, any comments on this?
>>>
>>> Jan
>>
>> hybrid_spinlock_t doesn't look right at first glance, it's use should be
>> limited to struct irq_desc and IRQ chips. I would have expected
>> hard_spinlock_t, but I might miss something.
>>
>> Assuming the gic-v3 IRQ chip is already marked / flagged as
>> IRQCHIP_PIPELINE_SAFE, right?
>>
>> Florian
> 
>>
> 
> 
> Thank you for your feedback
> 
> The gic-v3 IRQ chip is already marked with IRQCHIP_PIPELINE_SAFE. 
> The its_irq_chip is not marked with IRQCHIP_PIPELINE_SAFE. I added the flag and tested, but it did not have any effect.
> 
> Meanwhile, I read the code related to IRQCHIP_PIPELINE_SAFE. If the gic-v3 IRQ chip is not marked with IRQCHIP_PIPELINE_SAFE, a call trace like the following would be reported:
> MSI domain irqchip XXX is not pipeline-safe! or irqchip XXX is not pipeline-safe!
> However, I did not see any such message in dmsg logs.
> 
> Based on Florian's suggestion, I revisited the Xenomai 4 documentation regarding hybrid_spinlock_t and hard_spinlock_t. 
> I agree with Florian's point that hybrid_spinlock_t should be limited to struct irq_desc and IRQ chips, and that hard_spinlock_t is more appropriate for the ITS node lock.
> 
> I changed the lock to hard_spinlock_t and tested it. The call trace no longer appears and the system works fine.
> 
> The patch is as follows. Please help review it:
> 
> From e0cbc9316af331bf007c86e1fcab0ef8699b05c9 Mon Sep 17 00:00:00 2001
> From: zhanglin1040 <zhanglin1040@phytium.com.cn>
> Date: Mon, 13 Jul 2026 17:53:44 +0800
> Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
>  lock warning for ITS lock using hard spinlocks instead of hybrid spinlocks
> 

Missing commit message. Reason for the change needs to go here.

> ---
>  drivers/irqchip/irq-gic-v3-its.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 0e57735eac..3f2b02b8f4 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -94,7 +94,7 @@ struct its_device;
>   * list.
>   */
>  struct its_node {
> -    raw_spinlock_t        lock;
> +    hard_spinlock_t        lock;
>      struct mutex        dev_alloc_lock;
>      struct list_head    entry;
>      void __iomem        *base;
> -- 
> 2.34.1

Please send new versions of a patch in a new thread, incrementing the
patch version counter in the subject (here: "[PATCH v2] irqchip:
gic-v3-its: irq_pipeline: fix ...").

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

[PATCH v2] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band lock warning for ITS lock using hard spinlocks instead of hybrid spinlocks

[linz]

Thank you for your feedback


The gic-v3 IRQ chip is already marked with IRQCHIP_PIPELINE_SAFE. The its_irq_chip is not marked with IRQCHIP_PIPELINE_SAFE. I added the flag and tested, but it did not have any effect.

Meanwhile, I read the code related to IRQCHIP_PIPELINE_SAFE. If the gic-v3 IRQ chip is not marked with IRQCHIP_PIPELINE_SAFE, a call trace like the following would be reported:
MSI domain irqchip XXX is not pipeline-safe! or irqchip XXX is not pipeline-safe!
However, I did not see any such message in my logs.

Based on Florian's suggestion, I revisited the Xenomai 4 documentation regarding hybrid_spinlock_t and hard_spinlock_t. 
I agree with Florian's point that hybrid_spinlock_t should be limited to struct irq_desc and IRQ chips, and that hard_spinlock_t is more appropriate for the ITS node lock.

I changed the lock to hard_spinlock_t and tested it. The call trace no longer appears and the system works fine.

The patch is as follows. Please help review it:

From e0cbc9316af331bf007c86e1fcab0ef8699b05c9 Mon Sep 17 00:00:00 2001
From: zhanglin1040 <powertree@163.com>
Date: Mon, 13 Jul 2026 17:53:44 +0800
Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
 lock warning for ITS lock using hard spinlocks instead of hybrid spinlocks

---
 drivers/irqchip/irq-gic-v3-its.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0e57735eac..3f2b02b8f4 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -94,7 +94,7 @@ struct its_device;
  * list.
  */
 struct its_node {
-    raw_spinlock_t        lock;
+    hard_spinlock_t        lock;
     struct mutex        dev_alloc_lock;
     struct list_head    entry;
     void __iomem        *base;
-- 
2.34.1

Re: [PATCH v2] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band lock warning for ITS lock using hard spinlocks instead of hybrid spinlocks

[Jan Kiszka]

On 13.07.26 12:42, linz wrote:
> Thank you for your feedback
> 
> 
> The gic-v3 IRQ chip is already marked with IRQCHIP_PIPELINE_SAFE. The its_irq_chip is not marked with IRQCHIP_PIPELINE_SAFE. I added the flag and tested, but it did not have any effect.
> 
> Meanwhile, I read the code related to IRQCHIP_PIPELINE_SAFE. If the gic-v3 IRQ chip is not marked with IRQCHIP_PIPELINE_SAFE, a call trace like the following would be reported:
> MSI domain irqchip XXX is not pipeline-safe! or irqchip XXX is not pipeline-safe!
> However, I did not see any such message in my logs.
> 
> Based on Florian's suggestion, I revisited the Xenomai 4 documentation regarding hybrid_spinlock_t and hard_spinlock_t. 
> I agree with Florian's point that hybrid_spinlock_t should be limited to struct irq_desc and IRQ chips, and that hard_spinlock_t is more appropriate for the ITS node lock.
> 
> I changed the lock to hard_spinlock_t and tested it. The call trace no longer appears and the system works fine.
> 
> The patch is as follows. Please help review it:
> 

If you want to provide comments on your patch that should not go into
the git history (like the intro above)...

> From e0cbc9316af331bf007c86e1fcab0ef8699b05c9 Mon Sep 17 00:00:00 2001
> From: zhanglin1040 <powertree@163.com>
> Date: Mon, 13 Jul 2026 17:53:44 +0800
> Subject: [PATCH] irqchip: gic-v3-its: irq_pipeline: fix OOB context in-band
>  lock warning for ITS lock using hard spinlocks instead of hybrid spinlocks
> 
> ---

Put them right after this separator line.

But your patch is still lacking a commit message (text after subject and
that separator). And there is no Signed-off-by
(https://developercertificate.org/). Study how over patches look like
that are shared on this list.

Jan

>  drivers/irqchip/irq-gic-v3-its.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 0e57735eac..3f2b02b8f4 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -94,7 +94,7 @@ struct its_device;
>   * list.
>   */
>  struct its_node {
> -    raw_spinlock_t        lock;
> +    hard_spinlock_t        lock;
>      struct mutex        dev_alloc_lock;
>      struct list_head    entry;
>      void __iomem        *base;
> -- 
> 2.34.1

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

[PATCH v2] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock

[linz]

Thank you for your feedback

Under 6.6.63-dovetail2 environment, raw_spinlock_t for the ITS node lock triggers out‑of‑band context warning in irq‑pipeline code.
As suggested by Florian, hybrid_spinlock_t should be limited to struct irq_desc and irqchip internals. ITS node lock is more suitable to use hard_spinlock_t.

After replacing raw_spinlock_t with hard_spinlock_t, the call‑trace warning disappears and system runs stably.

In addition, the gic‑v3 irqchip already has IRQCHIP_PIPELINE_SAFE flag, while its_irq_chip lacks this flag.
Enabling IRQCHIP_PIPELINE_SAFE for its_irq_chip has no effect to resolve the warning.

Signed-off-by: zhanglin <powertree@163.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0e57735eac..3f2b02b8f4 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -94,7 +94,7 @@ struct its_device;
  * list.
  */
 struct its_node {
-	raw_spinlock_t		lock;
+	hard_spinlock_t		lock;
 	struct mutex		dev_alloc_lock;
 	struct list_head	entry;
 	void __iomem		*base;
-- 
2.34.1