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

[Jinjie Ruan <ruanjinjie@huawei.com>]

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
>