mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: s.grosjean@peak-system.fr
Cc: mkl@pengutronix.de, mailhol@kernel.org, wg@grandegger.com,
	error27@gmail.com, lukas.magel@posteo.net,
	linux-can@vger.kernel.org, linux-kernel@vger.kernel.org,
	tristmd@gmail.com, kuba@kernel.org
Subject: Re: [PATCH v7 12/13] can: peak_usb: dump undecodable URBs once and rate limit decode errors
Date: Sun, 01 Nov 2026 02:15:30 +0000	[thread overview]
Message-ID: <179349933002.3127.4498885660427450789@kernel.org> (raw)
In-Reply-To: <20261030-canfd_check_channel_idx-v7-12-fc4a3faf3acf@peak-system.fr>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] For an undecodable URB, the decoder's error message and the hex
  dump of the same URB are now gated by two separate net_ratelimit()…

--

can: peak_usb: dump undecodable URBs once and rate limit decode errors

This patch limits the hex dump of an undecodable URB to the
urb->actual_length bytes received. It removes the extra dumps from the
PCAN-USB FD and Pro decoders so that only peak_usb_read_bulk_callback()
dumps the URB. It also puts net_ratelimit() in front of the dump and the
decoder error messages.

[ ... ]

> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index e5198ec5c760d..1d306160fa354 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -266,10 +266,10 @@ static void peak_usb_read_bulk_callback(struct urb *urb)
>  		/* handle these kinds of msgs only if _start callback called */
>  		if (test_bit(PCAN_USB_STATE_STARTED, &dev->state)) {
>  			err = dev->adapter->dev_decode_buf(dev, urb);
> -			if (err)
> +			if (err && net_ratelimit())
>  				pcan_dump_mem("received usb message",
>  					      urb->transfer_buffer,
> -					      urb->transfer_buffer_length);
> +					      urb->actual_length);
>  		}
>  	}

[Severity: Low]
Can the decoder's error message and the dump of the same URB get split
up by two separate net_ratelimit() decisions?

Both calls use the single global net_ratelimit_state (5 * HZ interval,
burst of 10). For an undecodable URB, pcan_usb_fd_decode_buf() or
pcan_usb_pro_decode_buf() first calls net_ratelimit() for its own
message. peak_usb_read_bulk_callback() then calls it again for the dump.

For example, in pcan_usb_pro_decode_buf():

    if (!sizeof_rec) {
        if (net_ratelimit())
            netdev_err(netdev,
                       "got unsupported rec in usb msg:\n");
        err = -ENOTSUPP;
        break;
    }

Suppose the decoder's message takes the last token in the burst. The
dump in peak_usb_read_bulk_callback() is then suppressed. The "got
unsupported rec in usb msg:" line, which ends in a colon, gets logged
without the dump that should follow it. The reverse can also happen:
the dump appears without its message. The same applies to "bad msg hdr
len", "got frag rec" and "got short rec" in the FD and Pro decoders.

The per-record "unhandled msg type" and "unhandled rec type" messages
printed earlier in the loop for the same URB also use up tokens, and so
does other networking code. That makes it more likely that the dump for
a later fatal error in the URB is dropped.

Before this patch, the FD and Pro decoders always printed the dump right
after the message. Would making one rate-limit decision per URB, either
in the core or passed down to the decoders, keep each message and its
dump together?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261030-canfd_check_channel_idx-v7-0-fc4a3faf3acf%40peak-system.fr

  reply	other threads:[~2026-11-01  2:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 10:44 [PATCH v7 00/13] can: peak_usb: fixes, cleanup and input validation hardening Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 01/13] can: peak_usb: fix missing CAN_ERR_FLAG when reporting error counters Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 02/13] can: peak_usb: add missing includes Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 03/13] can: peak_usb: sort ctrlmode_supported flags Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 04/13] can: peak_usb: harden PCAN-USB message validation Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 05/13] can: peak_usb: replace open-coded bitmask operations with bitops Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 06/13] can: peak_usb: harden channel handling in PCAN-USB FD Stéphane Grosjean via B4 Relay
2026-11-01  2:15   ` netdev-bot+sashiko
2026-10-30 10:44 ` [PATCH v7 07/13] can: peak_usb: fix RX cursor desync for self-received RTR frames with SRR Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 08/13] can: peak_usb: reject records for unset channels in PCAN-USB Pro Stéphane Grosjean via B4 Relay
2026-11-01  2:15   ` netdev-bot+sashiko
2026-10-30 10:44 ` [PATCH v7 09/13] can: peak_usb: register the netdevs only once all channels are set up Stéphane Grosjean via B4 Relay
2026-10-30 10:44 ` [PATCH v7 10/13] can: peak_usb: validate the data length of PCAN-USB Pro CAN records Stéphane Grosjean via B4 Relay
2026-10-30 10:45 ` [PATCH v7 11/13] can: peak_usb: don't read past the message in PCAN-USB Pro decoders Stéphane Grosjean via B4 Relay
2026-10-30 10:45 ` [PATCH v7 12/13] can: peak_usb: dump undecodable URBs once and rate limit decode errors Stéphane Grosjean via B4 Relay
2026-11-01  2:15   ` netdev-bot+sashiko [this message]
2026-10-30 10:45 ` [PATCH v7 13/13] can: peak_usb: don't return an uninitialized PCAN-USB CAN channel ID Stéphane Grosjean via B4 Relay
2026-11-01  2:15   ` netdev-bot+sashiko

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=179349933002.3127.4498885660427450789@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=error27@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.magel@posteo.net \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=s.grosjean@peak-system.fr \
    --cc=tristmd@gmail.com \
    --cc=wg@grandegger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®