Re: [PATCH] irqchip: gic-v3-its: irq_pipeline: Fix OOB context in-band lock warning for ITS lock
Jan Kiszka <[email protected]> Fri, 10 Jul 2026 12:12:53 +0200
| Newsgroups | dev.linux.lists.xenomai |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > 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