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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20260121-illegal-impetuous-honeybee-e6ef40-mkl@pengutronix.de>
Date: Wed, 21 Jan 2026 15:37:01 +0100
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Oliver Hartkopp <socketcan@...tkopp.net>
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.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.

> 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   |

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