linux-kernel - Re: [PATCH net-next 1/5] net: dpaa: avoid on-stack arrays of NR

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: <Zo+/I5Rw0hp5wGeQ@gmail.com>
Date: Thu, 11 Jul 2024 04:16:51 -0700
From: Breno Leitao <leitao@...ian.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Madalin Bucur <madalin.bucur@....com>, linux-kernel@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net-next 1/5] net: dpaa: avoid on-stack arrays of NR_CPUS
 elements

Hello Vladimir,

On Thu, Jul 11, 2024 at 02:00:21AM +0300, Vladimir Oltean wrote:
> The dpaa-eth driver is written for PowerPC and Arm SoCs which have 1-24
> CPUs. It depends on CONFIG_NR_CPUS having a reasonably small value in
> Kconfig. Otherwise, there are 2 functions which allocate on-stack arrays
> of NR_CPUS elements, and these can quickly explode in size, leading to
> warnings such as:
> 
>   drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:3280:12: warning:
>   stack frame size (16664) exceeds limit (2048) in 'dpaa_eth_probe' [-Wframe-larger-than]
> 
> The problem is twofold:
> - Reducing the array size to the boot-time num_possible_cpus() (rather
>   than the compile-time NR_CPUS) creates a variable-length array,
>   which should be avoided in the Linux kernel.
> - Using NR_CPUS as an array size makes the driver blow up in stack
>   consumption with generic, as opposed to hand-crafted, .config files.
> 
> A simple solution is to use dynamic allocation for num_possible_cpus()
> elements (aka a small number determined at runtime).
> 
> Link: https://lore.kernel.org/all/202406261920.l5pzM1rj-lkp@intel.com/
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
Reviewed-by: Breno Leitao <leitao@...ian.org>

Thanks for working on it.

--breno