On 28.01.26 02:49, Jakub Kicinski wrote:

On Sun, 25 Jan 2026 21:15:55 +0100 Oliver Hartkopp wrote:

quoted

CAN bus related skbuffs (ETH_P_CAN/ETH_P_CANFD/ETH_P_CANXL) simply contain
CAN frame structs for CAN CC/FD/XL of skb->len length at skb->data.
Those CAN skbs do not have network/mac/transport headers nor other such
references for encapsulated protocols like ethernet/IP protocols.

To store data for CAN specific use-cases all CAN bus related skbuffs are
created with a 16 byte private skb headroom (struct can_skb_priv).
Using the skb headroom and accessing skb->head for this private data
led to several problems in the past likely due to "The struct can_skb_priv
business is highly unconventional for the networking stack." [1]

This patch set aims to remove the unconventional skb headroom usage for
CAN bus related skbuffs and use the common skb extensions instead.

This is fine. Wish we could make md_dst work, since skb_ext still burns
a bit in the skb (last extension bit in fact, next user will have to
bump the filed size). And you very much do not route these frames,
so dst would work perfectly fine. But whatever.

lore never received patch 6, tho, you'll need to repost.

Thanks for looking at it.

In fact patch 6 stuck in my providers mail system which responded this 
to (only) patch 6 ¯\_(ツ)_/¯

5.7.1 Refused by local policy. No SPAM please! (B-EX 
155302::1769588601-AC38E895-223F95BA/10/71040183929) see 
https://www.strato-hosting.co.uk/faq/product/why-are-my-emails-not-being-delivered 
[MSG0011]

As this could not been solved since Sunday I'll kindly ask Marc to send 
the attached v2 patchset (including your __u32 remark) to the mailing 
list, so that also the AI bot can take a look at it.

Many thanks!
Oliver