From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org, Marc Kleine-Budde <mkl@pengutronix.de>,
Jakub Kicinski <kuba@kernel.org>,
Vincent Mailhol <mailhol@kernel.org>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Simon Horman <horms@kernel.org>,
davem@davemloft.net
Subject: Re: [can-next 0/5] can: remove private skb headroom infrastructure
Date: Wed, 14 Jan 2026 12:10:57 +0100 [thread overview]
Message-ID: <aWd5wdMhpEuN9NFB@pengutronix.de> (raw)
In-Reply-To: <20260112150908.5815-1-socketcan@hartkopp.net>
Hi Oliver,
On Mon, Jan 12, 2026 at 04:09:03PM +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. To store the data for CAN specific use-cases
> unused space in CAN skbs is used, namely the inner protocol space for
> ethernet/IP encapsulation.
>
> [1] https://lore.kernel.org/linux-can/20260104074222.29e660ac@kernel.org/
>
> Oliver Hartkopp (5):
> can: use skb hash instead of private variable in headroom
> can: move can_iif from private headroom to struct sk_buff
> can: move frame length from private headroom to struct sk_buff
> can: remove private skb headroom infrastructure
> can: gw: use new can_gw_hops variable instead of re-using csum_start
>
> drivers/net/can/dev/skb.c | 45 ++++++++++++++++-----------------------
> include/linux/can/core.h | 1 +
> include/linux/can/skb.h | 33 ----------------------------
> include/linux/skbuff.h | 27 +++++++++++++++++------
> net/can/af_can.c | 35 +++++++++++++++++++-----------
> net/can/bcm.c | 13 ++++-------
> net/can/gw.c | 25 ++++++----------------
> net/can/isotp.c | 18 ++++++----------
> net/can/j1939/socket.c | 7 ++----
> net/can/j1939/transport.c | 13 ++++-------
> net/can/raw.c | 14 ++++++------
> 11 files changed, 92 insertions(+), 139 deletions(-)
J1939 related part seems to work without regressions.
For j1939:
Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Thank you!
Best Regards,
Oleksij
next prev parent reply other threads:[~2026-01-14 11:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 15:09 [can-next 0/5] can: remove private skb headroom infrastructure Oliver Hartkopp
2026-01-12 15:09 ` [can-next 1/5] can: use skb hash instead of private variable in headroom Oliver Hartkopp
2026-01-12 15:09 ` [can-next 2/5] can: move can_iif from private headroom to struct sk_buff Oliver Hartkopp
2026-01-12 15:09 ` [can-next 3/5] can: move frame length " Oliver Hartkopp
2026-01-12 15:09 ` [can-next 4/5] can: remove private skb headroom infrastructure Oliver Hartkopp
2026-01-12 15:09 ` [can-next 5/5] can: gw: use new can_gw_hops variable instead of re-using csum_start Oliver Hartkopp
2026-01-14 11:10 ` Oleksij Rempel [this message]
2026-01-15 15:37 ` [can-next 0/5] can: remove private skb headroom infrastructure Paolo Abeni
2026-01-16 10:31 ` Oliver Hartkopp
2026-01-17 17:15 ` Jakub Kicinski
2026-01-18 12:53 ` Oliver Hartkopp
2026-01-21 12:55 ` Oliver Hartkopp
2026-01-21 14:37 ` Marc Kleine-Budde
2026-01-22 17:44 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWd5wdMhpEuN9NFB@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox