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