Re: [PATCH v7 22/31] irqchip/gic-v5: Add GICv5 LPI/IPI support

[Lorenzo Pieralisi <lpieralisi@kernel.org>]

On Fri, Aug 08, 2025 at 09:20:30AM +0800, Jinjie Ruan wrote:
> 
> 
> On 2025/8/7 21:51, Lorenzo Pieralisi wrote:
> > On Thu, Aug 07, 2025 at 07:52:58PM +0800, Jinjie Ruan wrote:
> >>
> >>
> >> On 2025/7/3 18:25, Lorenzo Pieralisi wrote:
> >>> An IRS supports Logical Peripheral Interrupts (LPIs) and implement
> >>> Linux IPIs on top of it.
> >>>
> 
> [...]
> 
> >>> +static int __init gicv5_irs_init_ist_linear(struct gicv5_irs_chip_data *irs_data,
> >>> +					    unsigned int lpi_id_bits,
> >>> +					    unsigned int istsz)
> >>> +{
> >>> +	size_t l2istsz;
> >>> +	u32 n, cfgr;
> >>> +	void *ist;
> >>> +	u64 baser;
> >>> +	int ret;
> >>> +
> >>> +	/* Taken from GICv5 specifications 10.2.1.13 IRS_IST_BASER */
> >>> +	n = max(5, lpi_id_bits + 1 + istsz);
> >>> +
> >>> +	l2istsz = BIT(n + 1);
> >>> +	/*
> >>> +	 * Check memory requirements. For a linear IST we cap the
> >>> +	 * number of ID bits to a value that should never exceed
> >>> +	 * kmalloc interface memory allocation limits, so this
> >>> +	 * check is really belt and braces.
> >>> +	 */
> >>> +	if (l2istsz > KMALLOC_MAX_SIZE) {
> >>> +		u8 lpi_id_cap = ilog2(KMALLOC_MAX_SIZE) - 2 + istsz;
> >>> +
> >>> +		pr_warn("Limiting LPI ID bits from %u to %u\n",
> >>> +			lpi_id_bits, lpi_id_cap);
> >>> +		lpi_id_bits = lpi_id_cap;
> >>> +		l2istsz = KMALLOC_MAX_SIZE;
> >>> +	}
> >>> +
> >>> +	ist = kzalloc(l2istsz, GFP_KERNEL);
> >>
> >>
> >> When kmemleak is on, There is a memory leak occurring as below:
> >>
> >>
> >> unreferenced object 0xffff00080039a000 (size 4096):
> >>   comm "swapper/0", pid 0, jiffies 4294892296
> >>   hex dump (first 32 bytes):
> >>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >>   backtrace (crc 0):
> >>     kmemleak_alloc+0x34/0x40
> >>     __kmalloc_noprof+0x320/0x464
> >>     gicv5_irs_iste_alloc+0x1a4/0x484
> >>     gicv5_irq_lpi_domain_alloc+0xe4/0x194
> >>     irq_domain_alloc_irqs_parent+0x78/0xd8
> >>     gicv5_irq_ipi_domain_alloc+0x180/0x238
> >>     irq_domain_alloc_irqs_locked+0x238/0x7d4
> >>     __irq_domain_alloc_irqs+0x88/0x114
> >>     gicv5_of_init+0x284/0x37c
> >>     of_irq_init+0x3b8/0xb18
> >>     irqchip_init+0x18/0x40
> >>     init_IRQ+0x104/0x164
> >>     start_kernel+0x1a4/0x3d4
> >>     __primary_switched+0x8c/0x94
> > 
> > Thank you for reporting it.
> > 
> > It should be a false positive, we hand over the memory to the GIC but
> > never store the pointer anywhere (only its PA).
> > 
> > Patch below should "fix" it - well, it is obvious, we are telling
> > kmemleak to ignore the pointer value:
> 
> I also did not see any place in the code where these pointers are
> accessed, nor did I see in section "L2_ISTE, Level 2 interrupt state
> table entry" that L2_ISTE can be accessed by software. So, are these
> states of the LPI interrupt maintained by the GIC hardware itself?

The IST table is where interrupt state and configuration is kept -
it is managed by GIC IRS HW. SW controls interrupt configuration
through GIC instructions.

It is therefore a false positive, I will send the patch below for
inclusion.

Thanks,
Lorenzo

> > 
> > -- >8 --
> > diff --git a/drivers/irqchip/irq-gic-v5-irs.c b/drivers/irqchip/irq-gic-v5-irs.c
> > index ad1435a858a4..e8a576f66366 100644
> > --- a/drivers/irqchip/irq-gic-v5-irs.c
> > +++ b/drivers/irqchip/irq-gic-v5-irs.c
> > @@ -5,6 +5,7 @@
> >  
> >  #define pr_fmt(fmt)	"GICv5 IRS: " fmt
> >  
> > +#include <linux/kmemleak.h>
> >  #include <linux/log2.h>
> >  #include <linux/of.h>
> >  #include <linux/of_address.h>
> > @@ -117,6 +118,7 @@ static int __init gicv5_irs_init_ist_linear(struct gicv5_irs_chip_data *irs_data
> >  		kfree(ist);
> >  		return ret;
> >  	}
> > +	kmemleak_ignore(ist);
> >  
> >  	return 0;
> >  }
> > @@ -232,6 +234,7 @@ int gicv5_irs_iste_alloc(const u32 lpi)
> >  		kfree(l2ist);
> >  		return ret;
> >  	}
> > +	kmemleak_ignore(l2ist);
> >  
> >  	/*
> >  	 * Make sure we invalidate the cache line pulled before the IRS
> >