From: Simon Horman <horms@kernel.org>
To: Jimmy Assarsson <extja@kvaser.com>
Cc: linux-can@vger.kernel.org,
Jimmy Assarsson <jimmyassarsson@gmail.com>,
Marc Kleine-Budde <mkl@pengutronix.de>,
Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
netdev@vger.kernel.org
Subject: Re: [PATCH v2 01/11] can: kvaser_usb: Add support to control CAN LEDs on device
Date: Thu, 24 Jul 2025 19:26:11 +0100 [thread overview]
Message-ID: <20250724182611.GC1266901@horms.kernel.org> (raw)
In-Reply-To: <20250724092505.8-2-extja@kvaser.com>
On Thu, Jul 24, 2025 at 11:24:55AM +0200, Jimmy Assarsson wrote:
> Add support to turn on/off CAN LEDs on device.
>
> Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
...
> diff --git a/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c b/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c
...
> +static int kvaser_usb_hydra_set_led(struct kvaser_usb_net_priv *priv,
> + enum kvaser_usb_led_state state,
> + u16 duration_ms)
> +{
> + struct kvaser_usb *dev = priv->dev;
> + struct kvaser_cmd *cmd;
> + int ret;
> +
> + cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
> + if (!cmd)
> + return -ENOMEM;
> +
> + cmd->header.cmd_no = CMD_LED_ACTION_REQ;
> + kvaser_usb_hydra_set_cmd_dest_he(cmd, dev->card_data.hydra.sysdbg_he);
> + kvaser_usb_hydra_set_cmd_transid(cmd, kvaser_usb_hydra_get_next_transid(dev));
> +
> + cmd->led_action_req.duration_ms = cpu_to_le16(duration_ms);
> + cmd->led_action_req.action = state |
> + FIELD_PREP(KVASER_USB_HYDRA_LED_IDX_MASK,
> + KVASER_USB_HYDRA_LED_YELLOW_CH0_IDX +
> + KVASER_USB_HYDRA_LEDS_PER_CHANNEL * priv->channel);
> +
> + ret = kvaser_usb_send_cmd(dev, cmd, kvaser_usb_hydra_cmd_size(cmd));
When building this file with GCC 15.1.0 with KCFLAGS=-Warray-bounds
I see the following:
In file included from ./include/linux/byteorder/little_endian.h:5,
from ./arch/x86/include/uapi/asm/byteorder.h:5,
from ./include/linux/bitfield.h:12,
from drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c:15:
In function 'kvaser_usb_hydra_cmd_size',
inlined from 'kvaser_usb_hydra_set_led' at drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c:1993:38:
drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c:532:65: warning: array subscript 'struct kvaser_cmd_ext[0]' is partly outside array bounds of 'unsigned char[32]' [-Warray-bounds=]
532 | ret = le16_to_cpu(((struct kvaser_cmd_ext *)cmd)->len);
./include/uapi/linux/byteorder/little_endian.h:37:51: note: in definition of macro '__le16_to_cpu'
37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
| ^
drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c:532:23: note: in expansion of macro 'le16_to_cpu'
532 | ret = le16_to_cpu(((struct kvaser_cmd_ext *)cmd)->len);
| ^~~~~~~~~~~
In file included from ./include/linux/fs.h:46,
from ./include/linux/compat.h:17,
from ./arch/x86/include/asm/ia32.h:7,
from ./arch/x86/include/asm/elf.h:10,
from ./include/linux/elf.h:6,
from ./include/linux/module.h:19,
from ./include/linux/device/driver.h:21,
from ./include/linux/device.h:32,
from drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c:17:
In function 'kmalloc_noprof',
inlined from 'kzalloc_noprof' at ./include/linux/slab.h:1039:9,
inlined from 'kvaser_usb_hydra_set_led' at drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c:1979:8:
./include/linux/slab.h:905:24: note: object of size 32 allocated by '__kmalloc_cache_noprof'
905 | return __kmalloc_cache_noprof(
| ^~~~~~~~~~~~~~~~~~~~~~~
906 | kmalloc_caches[kmalloc_type(flags, _RET_IP_)][index],
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
907 | flags, size);
| ~~~~~~~~~~~~
if (cmd->header.cmd_no == CMD_EXTENDED)
ret = le16_to_cpu(((struct kvaser_cmd_ext *)cmd)->len);
GCC seems to know that:
* cmd was allocated sizeof(*cmd) = 32 bytes
* struct kvaser_cmd_ext is larger than this (96 bytes)
And it thinks that cmd->header.cmd_no might be CMD_EXTENDED.
This is not true, becuae .cmd_no is set to CMD_LED_ACTION_REQ
earlier in kvaser_usb_hydra_set_led. But still, GCC produces
a big fat warning.
On the one hand we might say this is a shortcoming in GCC,
a position I agree with. But on the other hand, we might follow
the pattern used elsewhere in this file for similar functions,
which seems to make GCC happy, I guess, and it is strictly a guess,
because less context is needed for it to analyse things correctly.
That is, do this:
diff --git a/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c b/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c
index 758fd13f1bf4..a4402b4845c6 100644
--- a/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c
+++ b/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c
@@ -1974,6 +1974,7 @@ static int kvaser_usb_hydra_set_led(struct kvaser_usb_net_priv *priv,
{
struct kvaser_usb *dev = priv->dev;
struct kvaser_cmd *cmd;
+ size_t cmd_len;
int ret;
cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
@@ -1981,6 +1982,7 @@ static int kvaser_usb_hydra_set_led(struct kvaser_usb_net_priv *priv,
return -ENOMEM;
cmd->header.cmd_no = CMD_LED_ACTION_REQ;
+ cmd_len = kvaser_usb_hydra_cmd_size(cmd);
kvaser_usb_hydra_set_cmd_dest_he(cmd, dev->card_data.hydra.sysdbg_he);
kvaser_usb_hydra_set_cmd_transid(cmd, kvaser_usb_hydra_get_next_transid(dev));
@@ -1990,7 +1992,7 @@ static int kvaser_usb_hydra_set_led(struct kvaser_usb_net_priv *priv,
KVASER_USB_HYDRA_LED_YELLOW_CH0_IDX +
KVASER_USB_HYDRA_LEDS_PER_CHANNEL * priv->channel);
- ret = kvaser_usb_send_cmd(dev, cmd, kvaser_usb_hydra_cmd_size(cmd));
+ ret = kvaser_usb_send_cmd(dev, cmd, cmd_len);
kfree(cmd);
return ret;
> + kfree(cmd);
> +
> + return ret;
> +}
...
next prev parent reply other threads:[~2025-07-24 18:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-24 9:24 [PATCH v2 00/11] can: kvaser_usb: Simplify identification of physical CAN interfaces Jimmy Assarsson
2025-07-24 9:24 ` [PATCH v2 01/11] can: kvaser_usb: Add support to control CAN LEDs on device Jimmy Assarsson
2025-07-24 18:26 ` Simon Horman [this message]
2025-07-25 12:44 ` Jimmy Assarsson
2025-07-26 19:48 ` Simon Horman
2025-07-24 9:24 ` [PATCH v2 02/11] can: kvaser_usb: Add support for ethtool set_phys_id() Jimmy Assarsson
2025-07-24 9:24 ` [PATCH v2 03/11] can: kvaser_usb: Assign netdev.dev_port based on device channel index Jimmy Assarsson
2025-07-24 9:24 ` [PATCH v2 04/11] can: kvaser_usb: Add intermediate variables Jimmy Assarsson
2025-07-24 9:24 ` [PATCH v2 05/11] can: kvaser_usb: Move comment regarding max_tx_urbs Jimmy Assarsson
2025-07-24 9:25 ` [PATCH v2 06/11] can: kvaser_usb: Store the different firmware version components in a struct Jimmy Assarsson
2025-07-24 9:25 ` [PATCH v2 07/11] can: kvaser_usb: Store additional device information Jimmy Assarsson
2025-07-24 9:25 ` [PATCH v2 08/11] can: kvaser_usb: Add devlink support Jimmy Assarsson
2025-07-24 9:25 ` [PATCH v2 09/11] can: kvaser_usb: Expose device information via devlink info_get() Jimmy Assarsson
2025-07-25 3:23 ` Vincent Mailhol
2025-07-24 9:25 ` [PATCH v2 10/11] can: kvaser_usb: Add devlink port support Jimmy Assarsson
2025-07-24 9:25 ` [PATCH v2 11/11] Documentation: devlink: add devlink documentation for the kvaser_usb driver Jimmy Assarsson
2025-07-25 3:27 ` Vincent Mailhol
2025-07-25 3:29 ` [PATCH v2 00/11] can: kvaser_usb: Simplify identification of physical CAN interfaces Vincent Mailhol
2025-07-25 12:45 ` Jimmy Assarsson
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=20250724182611.GC1266901@horms.kernel.org \
--to=horms@kernel.org \
--cc=extja@kvaser.com \
--cc=jimmyassarsson@gmail.com \
--cc=linux-can@vger.kernel.org \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox