netdev - Re: [can-next 0/5] can: remove private skb headroom infrastructure

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 for Android: free password hash cracker in your pocket

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

Message-ID: <b539ae8a-fcdb-4486-a03b-8a755ee090cc@hartkopp.net>
Date: Thu, 22 Jan 2026 18:44:00 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 linux-can@...r.kernel.org, Oleksij Rempel <o.rempel@...gutronix.de>,
 Vincent Mailhol <mailhol@...nel.org>, netdev@...r.kernel.org,
 Eric Dumazet <edumazet@...gle.com>, Simon Horman <horms@...nel.org>,
 davem@...emloft.net
Subject: Re: [can-next 0/5] can: remove private skb headroom infrastructure


On 21.01.26 15:37, Marc Kleine-Budde wrote:
> On 21.01.2026 13:55:47, Oliver Hartkopp wrote:
>> I'm not sure how intense you followed my discussion with Jakub and Paolo
>> about my attempt to move the CAN skb specifc content (8 bytes) away from the
>> problematic skb->head reference an hold it directly in struct sk_buff?
>>
>> Meanwhile I sent a v2 patch set which has been dropped from netdev patchwork
>> because of its can-next mail subject:
>>
>> https://lore.kernel.org/linux-can/20260117132824.3649-1-socketcan@hartkopp.net/
>>
>> I've been running the patches for quite a while now and feel very confident
>> that the solution is very efficient and safe for either CAN skbs and non-CAN
>> skbs.
>>
>> To be more clear in the struct sk_buff changes I would change the comments
>> in my next respin like this:
>>
>> 	union {
>> 		/* skb->encapsulation = true */
>> 		struct {
>> 			/* eth/ip encapsulation / tunneling */
>> 			union {
>> 				__be16	inner_protocol;
>> 				__u8	inner_ipproto;
>> 			};
>>
>> 			__u16	inner_transport_header;
>> 			__u16	inner_network_header;
>> 			__u16	inner_mac_header;
>> 		};
>>
>> 		/* skb->encapsulation = false */
>> #if IS_ENABLED(CONFIG_CAN)
>> 		struct {
>> 			/* CAN skb content (ETH_P_CAN*) */
>> 			int	can_iif;
>> 			__u16	can_framelen;
>> 			__u16	can_gw_hops;
>> 		};
>> #endif
>> 	};
>>
>> And I wonder if it would make sense to add a WARN_ON_ONCE() in can_rcv() and
>> friends?
>>
>> What is your opinion about the patch set?
> 
> We have to convince the netdev people why we cannot use metadata_dst or
> skb extentions but put things in other more os less arbitrary places.

I was only looking into metadata_dst which looked scary to me.

But the skb extensions look promising. It's pretty good to understand 
and sticks to the skb until it is free'd. And cloning/freeing works 
automatically and handles the skb extension seamlessly.

So it mainly costs another kmem_cache_alloc() ...

I'll give it a try.

Best regards,
Oliver

> 
>> Should I make it a net-next patch set to restart the discussion there?
> 
> Rather continue the discussion :)
> 
> 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   |