linux-kernel - Re: [PATCH net-next v8 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] [day] [month] [year] [list]

Message-ID: <89bb75ac-9dca-4593-8a0f-995eefb843c6@hartkopp.net>
Date: Thu, 5 Feb 2026 13:37:40 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Paolo Abeni <pabeni@...hat.com>, Florian Westphal <fw@...len.de>,
 Marc Kleine-Budde <mkl@...gutronix.de>, Vincent Mailhol
 <mailhol@...nel.org>, Robin van der Gracht <robin@...tonic.nl>,
 Oleksij Rempel <o.rempel@...gutronix.de>, kernel@...gutronix.de,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Simon Horman <horms@...nel.org>
Cc: linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH net-next v8 0/6] move CAN skb headroom content to skb
 extensions

On 05.02.26 11:54, Paolo Abeni wrote:
> On 2/3/26 8:19 PM, Oliver Hartkopp wrote:
>> When CONFIG_CAN is enabled the skbuff_ext_cache element would increase
>> in size by 8 bytes (sizeof(struct can_skb_ext)) on my machine (see
>> pahole output below).
>>
>> So when everything is enabled it would be
>>
>> CONFIG_SKB_EXTENSIONS
>> 8  bytes sizeof(struct skb_ext)
>> CONFIG_BRIDGE_NETFILTER
>> 32 bytes sizeof(struct nf_bridge_info)
>> CONFIG_XFRM
>> 88 bytes sizeof(struct sec_path)
>> CONFIG_NET_TC_SKB_EXT
>> 16 bytes sizeof(struct tc_skb_ext)
>> CONFIG_MPTCP
>> 32 bytes sizeof(struct mptcp_ext)
>> CONFIG_MCTP_FLOWS
>> 8  bytes sizeof(struct mctp_flow)
>> CONFIG_INET_PSP
>> 8  bytes sizeof(struct psp_skb_ext)
>> CONFIG_CAN
>> 8  bytes sizeof(struct can_skb_ext)
>> ---------
>> 200 bytes total skbuff_ext_cache element size
>> (255 * 8 = 2040 bytes max space for skb extension users).
>>
>> Does this answer your question?
> 
> Yes, thank you for the collaboration!
> 
> I think there is mistake above: sizeof(struct skb_ext) should be 16 when
> more than 3 skb extensions are enabled.

Oh, yes. You are right!

struct skb_ext {
         refcount_t                 refcnt;               /*     0     4 */
         u8                         offset[7];            /*     4     7 */
         u8                         chunks;               /*    11     1 */

         /* XXX 4 bytes hole, try to pack */

         char                       data[] 
__attribute__((__aligned__(8))); /*    16     0 */

         /* size: 16, cachelines: 1, members: 4 */
         /* sum members: 12, holes: 1, sum holes: 4 */
         /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
         /* last cacheline: 16 bytes */
} __attribute__((__aligned__(8)));

After I enabled all kernel configs that would increase the skb 
extensions I just copied the missing pahole structs into the mail - not 
looking for the struct skb_ext again ...

> that means that the total extension size already exceeds the 3
> cachelines (192 bytes) boundary when all extensions are enabled and
> adding the CAN one should not cause any regressions is such scenario.
> 
> Note that the "all skb extensions enabled" is possibly/likely NOT the
> most common/relevant one, but I think there is some space we can squeeze
> elsewhere if needed.

Right.

Many thanks!
Oliver