netdev - Re: question about size of sk_buff and skb_shared

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: <CABGNeczts-LsPLVOp_G24b9V-XnZXCKojKtWcN822wAzXunpuw@mail.gmail.com>
Date:   Tue, 18 Apr 2017 22:20:32 -0700
From:   Code Soldier1 <codesoldier1@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: question about size of sk_buff and skb_shared_info

On Tue, Apr 18, 2017 at 5:47 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> For the last time, do not top post on netdev.

Sorry about that.
>
> On Tue, 2017-04-18 at 17:15 -0700, Code Soldier1 wrote:
>> I am not suggesting that we do not do cache alignment. That is
>> required for performance. I have gone through this exercise because I
>> need to add a field to sk_buff and I want to do that without causing
>> any adverse effects.
>>
>> Now that we have discovered that there are 40 bytes that can be used
>> without any adverse effect, may I increase skb->cb by 8 bytes ?
>>
>
> skb->cb is already 48 bytes, not 40.

That is not what I am referring to above. What I am pointing out is
that since skb is not a multiple of cache line size it accesses the
whole cache line but uses only part of the cache line, leaving 40
bytes unused. I would like to use 8 out of those 40 bytes to extend
the size of skb->cb.

>
>> If not then may I increase skb_shared_info -- However that would have
>> to be by 64bytes.
>
>
> You will have a very hard time to convince us that this 8 byte field is
> needed on all skbs, regardless of current sk_buff size.
>

Protocols use as much space as needed and leave the rest for future
use. Since there is no overhead, I don't understand the concern. Can
you please elaborate.

-- 
CS1