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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c8e3dc2c-617b-2988-10ff-88082370e787@huawei.com>
Date: Fri, 8 Aug 2025 09:20:30 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
CC: Marc Zyngier <maz@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Will
 Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>, Sascha Bischoff
	<sascha.bischoff@....com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Timothy Hayes <timothy.hayes@....com>, Bjorn Helgaas <bhelgaas@...gle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>, Peter Maydell
	<peter.maydell@...aro.org>, Mark Rutland <mark.rutland@....com>, Jiri Slaby
	<jirislaby@...nel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-pci@...r.kernel.org>
Subject: Re: [PATCH v7 22/31] irqchip/gic-v5: Add GICv5 LPI/IPI support



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
>