[PATCH v5 0/3] can_rx_offload keeps a lockless irq_queue that the IRQ handlers fill and that is later spliced under skb_queue.lock into the NAPI-facing skb_queue. This works as long as a single context fills the irq_queue. flexcan with FLEXCAN_QUIRK_SECONDARY_MB_IRQ and mcf5441x use two mailbox IRQ lines. When those are affined to different CPUs the two handlers can enqueue into the same list at the same time and corrupt it.

[Ciprian Marian Costea]

On 9/7/2026 4:49 PM, Marc Kleine-Budde wrote:
> On 07.09.2026 12:49:39, Ciprian Costea wrote:
>> From: Ciprian Marian Costea <ciprianmarian.costea at oss.nxp.com>
>>
>> This series:
>>    1. Makes the irq_queue per-CPU so the handlers no longer share a list.
> 
> As sashiko pointed out, using per-CPU variables in a preemptible context
> doesn't work. When proposing to use per-CPU variables I haven't thought
> that far. So in hindsight this approach is not good.
> 
> What about following what NAPI does. Have a dedicated data structure per
> IRQ. I think these ones are needed:
> 
> | 	struct sk_buff_head skb_irq_queue;
> | 	u32 skb_queue_len_max;
> |
> | 	unsigned int mb_first;
> | 	unsigned int mb_last;
> 
> And pass them to can_rx_offload_queue_timestamp() and
> can_rx_offload_irq_finish().
> 
> regards,
> Marc
> 

Hello Marc,

Thanks for replying.
Indeed the per-CPU approach should be dropped. I've also missed the 
PREEMPT_RT case.
Your proposal seems better than even having a dedicated spinlock for 
skb_irq_queue operations as I've originally thought.

One thing to confirm before I go ahead and implement this approach for 
V6: Having the following connected patchset in mind [1] which separates 
the IRQ handlers, both flexcan MB IRQs currently run flexcan_do_mb() 
over the full iflag. Therefore, to actually separate the producers I'll 
have each IRQ drain only its own mb_first..mb_last range into its own 
queue - is this the right approach ?


[1] 
https://lore.kernel.org/all/20260831143449.12828-1-ciprianmarian.costea@oss.nxp.com/T/#t

Regards,
Ciprian