linux-kernel - Re: [PATCH] devlink: move DEVLINK_ATTR

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: <dugteasq4zxwqww4hepsomjga4rxpyk76p5eudk7yrs74ub4vl@cusxvnvgmmtz>
Date: Wed, 9 Jul 2025 12:05:24 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Arnd Bergmann <arnd@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Carolina Jubran <cjubran@...dia.com>, 
	Tariq Toukan <tariqt@...dia.com>, Cosmin Ratiu <cratiu@...dia.com>, Mark Bloch <mbloch@...dia.com>, 
	Arnd Bergmann <arnd@...db.de>, Simon Horman <horms@...nel.org>, Joe Damato <jdamato@...tly.com>, 
	Przemek Kitszel <przemyslaw.kitszel@...el.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] devlink: move DEVLINK_ATTR_MAX-sized array off stack

Tue, Jul 08, 2025 at 06:06:43PM +0200, arnd@...nel.org wrote:
>From: Arnd Bergmann <arnd@...db.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@...db.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?