All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ciprian Costea" <ciprianmarian.costea@oss.nxp.com>
Cc: "Vincent Mailhol" <mailhol@kernel.org>,
	imx@lists.linux.dev, Frank.Li@kernel.org,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	linux-can@vger.kernel.org
Subject: Re: [PATCH v2 2/2] can: at91_can: add missing can_rx_offload_del() in at91_can_remove()
Date: Tue, 01 Sep 2026 08:49:30 +0000	[thread overview]
Message-ID: <20260901084931.0AB111F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260901083927.316283-3-ciprianmarian.costea@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The driver ignores the return value of `can_rx_offload_add_timestamp()`, leading to a kernel panic upon allocation failure, and also misses cleanup in the probe error path.
--

commit 480793d438a773b528d044a7ee532ec7fbf0bc18
Author: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>

can: at91_can: add missing can_rx_offload_del() in at91_can_remove()

at91_can_probe() sets up rx-offload via can_rx_offload_add_timestamp(),
but at91_can_remove() never calls can_rx_offload_del(). The NAPI
instance added by can_rx_offload_add_timestamp() is therefore never
removed on unbind.

[ ... ]

> diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
> index 58da323f14d7c..3ee908817add8 100644
> --- a/drivers/net/can/at91_can.c
> +++ b/drivers/net/can/at91_can.c
> @@ -1165,6 +1165,8 @@ static void at91_can_remove(struct platform_device *pdev)
>  
>  	unregister_netdev(dev);
>  
> +	can_rx_offload_del(&priv->offload);
> +

[Severity: High]
This isn't a bug introduced by this patch, but while fixing this missing
cleanup in at91_can_remove(), is there a similar leak in the at91_can_probe()
error path?

If register_candev() fails during probe, the exit_free error path is taken
but it misses calling can_rx_offload_del(). Could this leave a dangling NAPI
instance and leak the per-CPU queues?

drivers/net/can/at91_can.c:at91_can_probe() {
	...
	err = register_candev(dev);
	if (err) {
		dev_err(&pdev->dev, "registering netdev failed\n");
		goto exit_free;
	}
	...
 exit_free:
	free_candev(dev);
	...
}

Additionally, the return value of can_rx_offload_add_timestamp() in
at91_can_probe() is ignored.

If the allocation fails under memory pressure and returns an error like
-ENOMEM, the probe continues without allocating the per-CPU queues. When a
hardware interrupt eventually fires:

drivers/net/can/dev/rx-offload.c:can_rx_offload_irq_offload_timestamp() {
	...
	irq_queue = get_cpu_ptr(offload->skb_irq_queue);
	...
	__skb_queue_add_sort(irq_queue, skb, can_rx_offload_compare);
}

Could this result in passing an uninitialized NULL skb_irq_queue pointer to
get_cpu_ptr(), producing an invalid memory address and causing a fatal page
fault when dereferenced by __skb_queue_add_sort()?

Does at91_can_probe() need to check the return value of
can_rx_offload_add_timestamp() and handle the allocation error?

>  	iounmap(priv->reg_base);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901083927.316283-1-ciprianmarian.costea@oss.nxp.com?part=2

  reply	other threads:[~2026-09-01  8:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01  8:39 [PATCH v2 0/2] can: rx-offload: make skb_irq_queue per-CPU Ciprian Costea
2026-09-01  8:39 ` [PATCH v2 1/2] " Ciprian Costea
2026-09-01  8:56   ` sashiko-bot
2026-09-01  8:39 ` [PATCH v2 2/2] can: at91_can: add missing can_rx_offload_del() in at91_can_remove() Ciprian Costea
2026-09-01  8:49   ` sashiko-bot [this message]
2026-09-01  9:02     ` Ciprian Marian Costea

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=20260901084931.0AB111F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=ciprianmarian.costea@oss.nxp.com \
    --cc=imx@lists.linux.dev \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=o.rempel@pengutronix.de \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=socketcan@hartkopp.net \
    /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.