netdev - Re: [net-next 0/6] move CAN skb headroom content to skb extensions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260128-booby-of-phenomenal-proficiency-4db5ab-mkl@pengutronix.de>
Date: Wed, 28 Jan 2026 10:07:13 +0100
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Oliver Hartkopp <socketcan@...tkopp.net>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org, 
	linux-can@...r.kernel.org
Subject: Re: [net-next 0/6] move CAN skb headroom content to skb extensions

On 28.01.2026 09:42:14, Oliver Hartkopp wrote:
> On 28.01.26 02:49, Jakub Kicinski wrote:
> > On Sun, 25 Jan 2026 21:15:55 +0100 Oliver Hartkopp wrote:
> > > 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.

I'll do. In the mean time, please have a look at b4, it has support for
sending patches via a web hook.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)