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
> >
