Re: [PATCH v5 3/8] can: flexcan: split rx/tx masks per mailbox IRQ line

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Concurrent execution of split IRQ handlers corrupts the lockless `skb_irq_queue`.
--

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

can: flexcan: split rx/tx masks per mailbox IRQ line

This patch splits the mailbox IRQ handling into separate lines for MB0 and
MB1 on S32G2 platforms. It passes a mailbox mask into flexcan_do_mb() to
ensure each IRQ handler only processes the rx and tx flags for its designated
mailboxes.

> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index 7dde2e623defe..0ed838f0719aa 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
[ ... ]
> @@ -1244,8 +1255,14 @@ static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
>  	struct net_device *dev = dev_id;
>  	struct flexcan_priv *priv = netdev_priv(dev);
>  	irqreturn_t handled;
> +	u64 mb_mask = ~0ULL;
> +
> +	if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> +		mb_mask = (irq == priv->irq_secondary_mb) ?
> +			  FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK :
> +			  FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK;
>  
> -	handled = flexcan_do_mb(dev);
> +	handled = flexcan_do_mb(dev, mb_mask);

[Severity: Critical]
This is a pre-existing issue, but since there are two separate IRQ lines 
assigned to flexcan_irq_mb(), could they fire concurrently on different CPUs
and corrupt the rx-offload queues?

Both handlers call flexcan_do_mb() which then calls 
can_rx_offload_irq_offload_timestamp():

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

Because __skb_queue_add_sort() modifies the list locklessly, it assumes a
strict single-IRQ serialization model. If the primary and secondary MB IRQ
handlers execute at the same time, this will lead to concurrent insertions
corrupting the doubly-linked list. Is there any mechanism restricting the CPU
affinity or preventing concurrent execution of these IRQs?

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