[PATCH] devlink: move DEVLINK_ATTR_MAX-sized array off stack

[PATCH] devlink: move DEVLINK_ATTR_MAX-sized array off stack

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

There are many possible devlink attributes, so having an array of them
on the stack can cause a warning for excessive stack usage:

net/devlink/rate.c: In function 'devlink_nl_rate_tc_bw_parse':
net/devlink/rate.c:382:1: error: the frame size of 1648 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

Change this to dynamic allocation instead.

Fixes: 566e8f108fc7 ("devlink: Extend devlink rate API with traffic classes bandwidth management")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I see that only two of the many array entries are actually used in this
function: DEVLINK_ATTR_RATE_TC_INDEX and DEVLINK_ATTR_RATE_TC_BW. If there
is an interface to extract just a single entry, using that would be
a little easier than the kcalloc().
---
 net/devlink/rate.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/net/devlink/rate.c b/net/devlink/rate.c
index d39300a9b3d4..e4083649748f 100644
--- a/net/devlink/rate.c
+++ b/net/devlink/rate.c
@@ -346,19 +346,23 @@ static int devlink_nl_rate_tc_bw_parse(struct nlattr *parent_nest, u32 *tc_bw,
 				       unsigned long *bitmap,
 				       struct netlink_ext_ack *extack)
 {
-	struct nlattr *tb[DEVLINK_ATTR_MAX + 1];
+	struct nlattr **tb;
 	u8 tc_index;
 	int err;
 
+	tb = kcalloc(DEVLINK_ATTR_MAX + 1, sizeof(struct nlattr *), GFP_KERNEL);
+	if (!tb)
+		return -ENOMEM;
 	err = nla_parse_nested(tb, DEVLINK_ATTR_MAX, parent_nest,
 			       devlink_dl_rate_tc_bws_nl_policy, extack);
 	if (err)
-		return err;
+		goto out;
 
+	err = -EINVAL;
 	if (!tb[DEVLINK_ATTR_RATE_TC_INDEX]) {
 		NL_SET_ERR_ATTR_MISS(extack, parent_nest,
 				     DEVLINK_ATTR_RATE_TC_INDEX);
-		return -EINVAL;
+		goto out;
 	}
 
 	tc_index = nla_get_u8(tb[DEVLINK_ATTR_RATE_TC_INDEX]);
@@ -366,19 +370,21 @@ static int devlink_nl_rate_tc_bw_parse(struct nlattr *parent_nest, u32 *tc_bw,
 	if (!tb[DEVLINK_ATTR_RATE_TC_BW]) {
 		NL_SET_ERR_ATTR_MISS(extack, parent_nest,
 				     DEVLINK_ATTR_RATE_TC_BW);
-		return -EINVAL;
+		goto out;
 	}
 
 	if (test_and_set_bit(tc_index, bitmap)) {
 		NL_SET_ERR_MSG_FMT(extack,
 				   "Duplicate traffic class index specified (%u)",
 				   tc_index);
-		return -EINVAL;
+		goto out;
 	}
 
 	tc_bw[tc_index] = nla_get_u32(tb[DEVLINK_ATTR_RATE_TC_BW]);
 
-	return 0;
+out:
+	kfree(tb);
+	return err;
 }
 
 static int devlink_nl_rate_tc_bw_set(struct devlink_rate *devlink_rate,
-- 
2.39.5

Re: [PATCH] devlink: move DEVLINK_ATTR_MAX-sized array off stack

[Simon Horman]

On Tue, Jul 08, 2025 at 06:06:43PM +0200, Arnd Bergmann wrote:

...

> diff --git a/net/devlink/rate.c b/net/devlink/rate.c

...

> +	err = -EINVAL;

...

>  	tc_bw[tc_index] = nla_get_u32(tb[DEVLINK_ATTR_RATE_TC_BW]);
>  
> -	return 0;

Hi Arnd,

It looks like err will be -EINVAL here, which doesn't seem desirable.
I'd just return 0 here.

And, FWIIW, I'd only set err when it is needed, even if that
means some duplication. I think that is an idiomatic approach,
at least within Networking.

> +out:
> +	kfree(tb);
> +	return err;
>  }

...

-- 
pw-bot: changes-requested

Re: [PATCH] devlink: move DEVLINK_ATTR_MAX-sized array off stack

[Jiri Pirko]

Tue, Jul 08, 2025 at 06:06:43PM +0200, arnd@kernel.org wrote:
>From: Arnd Bergmann <arnd@arndb.de>
>
>There are many possible devlink attributes, so having an array of them
>on the stack can cause a warning for excessive stack usage:
>
>net/devlink/rate.c: In function 'devlink_nl_rate_tc_bw_parse':
>net/devlink/rate.c:382:1: error: the frame size of 1648 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>
>Change this to dynamic allocation instead.
>
>Fixes: 566e8f108fc7 ("devlink: Extend devlink rate API with traffic classes bandwidth management")
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>---
>I see that only two of the many array entries are actually used in this
>function: DEVLINK_ATTR_RATE_TC_INDEX and DEVLINK_ATTR_RATE_TC_BW. If there
>is an interface to extract just a single entry, using that would be
>a little easier than the kcalloc().
>---
> net/devlink/rate.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
>diff --git a/net/devlink/rate.c b/net/devlink/rate.c
>index d39300a9b3d4..e4083649748f 100644
>--- a/net/devlink/rate.c
>+++ b/net/devlink/rate.c
>@@ -346,19 +346,23 @@ static int devlink_nl_rate_tc_bw_parse(struct nlattr *parent_nest, u32 *tc_bw,
> 				       unsigned long *bitmap,
> 				       struct netlink_ext_ack *extack)
> {
>-	struct nlattr *tb[DEVLINK_ATTR_MAX + 1];
>+	struct nlattr **tb;
> 	u8 tc_index;
> 	int err;
> 
>+	tb = kcalloc(DEVLINK_ATTR_MAX + 1, sizeof(struct nlattr *), GFP_KERNEL);
>+	if (!tb)
>+		return -ENOMEM;
> 	err = nla_parse_nested(tb, DEVLINK_ATTR_MAX, parent_nest,
> 			       devlink_dl_rate_tc_bws_nl_policy, extack);
> 	if (err)
>-		return err;
>+		goto out;
> 
>+	err = -EINVAL;
> 	if (!tb[DEVLINK_ATTR_RATE_TC_INDEX]) {
> 		NL_SET_ERR_ATTR_MISS(extack, parent_nest,
> 				     DEVLINK_ATTR_RATE_TC_INDEX);
>-		return -EINVAL;
>+		goto out;
> 	}
> 
> 	tc_index = nla_get_u8(tb[DEVLINK_ATTR_RATE_TC_INDEX]);
>@@ -366,19 +370,21 @@ static int devlink_nl_rate_tc_bw_parse(struct nlattr *parent_nest, u32 *tc_bw,
> 	if (!tb[DEVLINK_ATTR_RATE_TC_BW]) {
> 		NL_SET_ERR_ATTR_MISS(extack, parent_nest,
> 				     DEVLINK_ATTR_RATE_TC_BW);
>-		return -EINVAL;
>+		goto out;
> 	}
> 
> 	if (test_and_set_bit(tc_index, bitmap)) {
> 		NL_SET_ERR_MSG_FMT(extack,
> 				   "Duplicate traffic class index specified (%u)",
> 				   tc_index);
>-		return -EINVAL;
>+		goto out;
> 	}
> 
> 	tc_bw[tc_index] = nla_get_u32(tb[DEVLINK_ATTR_RATE_TC_BW]);
> 
>-	return 0;
>+out:
>+	kfree(tb);
>+	return err;

Isn't it about the time to start to leverage or cleanup infrastructure
for things like this? /me covers against all the eggs flying in
I mean, there are subsystems where it's perfectly fine to use it.
Can we start with frees like this one and avoid the silly gotos?

Re: [PATCH] devlink: move DEVLINK_ATTR_MAX-sized array off stack

[Arnd Bergmann]

On Wed, Jul 9, 2025, at 12:05, Jiri Pirko wrote:
> Tue, Jul 08, 2025 at 06:06:43PM +0200, arnd@kernel.org wrote:
>
> Isn't it about the time to start to leverage or cleanup infrastructure
> for things like this? /me covers against all the eggs flying in
> I mean, there are subsystems where it's perfectly fine to use it.
> Can we start with frees like this one and avoid the silly gotos?

I had so far resisted learning about how those actually work, thanks
for pushing me to finally trying it out ;-)

I've sent a v2 now.

    Arnd