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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ