From: Breno Leitao <leitao@debian.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Madalin Bucur <madalin.bucur@nxp.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next 1/5] net: dpaa: avoid on-stack arrays of NR_CPUS elements
Date: Thu, 11 Jul 2024 04:16:51 -0700 [thread overview]
Message-ID: <Zo+/I5Rw0hp5wGeQ@gmail.com> (raw)
In-Reply-To: <20240710230025.46487-2-vladimir.oltean@nxp.com>
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@nxp.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Thanks for working on it.
--breno
WARNING: multiple messages have this Message-ID (diff)
From: Breno Leitao <leitao@debian.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Madalin Bucur <madalin.bucur@nxp.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next 1/5] net: dpaa: avoid on-stack arrays of NR_CPUS elements
Date: Thu, 11 Jul 2024 04:16:51 -0700 [thread overview]
Message-ID: <Zo+/I5Rw0hp5wGeQ@gmail.com> (raw)
In-Reply-To: <20240710230025.46487-2-vladimir.oltean@nxp.com>
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@nxp.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Thanks for working on it.
--breno
next prev parent reply other threads:[~2024-07-11 11:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 23:00 [PATCH net-next 0/5] Eliminate CONFIG_NR_CPUS dependency in dpaa-eth and enable COMPILE_TEST in fsl_qbman Vladimir Oltean
2024-07-10 23:00 ` Vladimir Oltean
2024-07-10 23:00 ` [PATCH net-next 1/5] net: dpaa: avoid on-stack arrays of NR_CPUS elements Vladimir Oltean
2024-07-10 23:00 ` Vladimir Oltean
2024-07-11 11:16 ` Breno Leitao [this message]
2024-07-11 11:16 ` Breno Leitao
2024-07-10 23:00 ` [PATCH net-next 2/5] net: dpaa: eliminate NR_CPUS dependency in egress_fqs[] and conf_fqs[] Vladimir Oltean
2024-07-10 23:00 ` Vladimir Oltean
2024-07-13 22:35 ` Jakub Kicinski
2024-07-13 22:35 ` Jakub Kicinski
2024-07-13 22:37 ` Vladimir Oltean
2024-07-13 22:37 ` Vladimir Oltean
2024-07-10 23:00 ` [PATCH net-next 3/5] net: dpaa: stop ignoring TX queues past the number of CPUs Vladimir Oltean
2024-07-10 23:00 ` Vladimir Oltean
2024-07-10 23:00 ` [PATCH net-next 4/5] net: dpaa: no need to make sure all CPUs receive a corresponding Tx queue Vladimir Oltean
2024-07-10 23:00 ` Vladimir Oltean
2024-07-10 23:00 ` [PATCH net-next 5/5] soc: fsl: qbman: FSL_DPAA depends on COMPILE_TEST Vladimir Oltean
2024-07-10 23:00 ` Vladimir Oltean
2024-07-12 12:14 ` Vladimir Oltean
2024-07-12 12:14 ` Vladimir Oltean
2024-07-12 13:52 ` Breno Leitao
2024-07-12 13:52 ` Breno Leitao
2024-07-11 13:23 ` [PATCH net-next 0/5] Eliminate CONFIG_NR_CPUS dependency in dpaa-eth and enable COMPILE_TEST in fsl_qbman Madalin Bucur (OSS)
2024-07-11 13:23 ` Madalin Bucur (OSS)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zo+/I5Rw0hp5wGeQ@gmail.com \
--to=leitao@debian.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=madalin.bucur@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.