netdev - Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALYGNiMUVjH4K3xtzHjf3o5XujFvVFrEvbL90o_fzEU8bWoQgg@mail.gmail.com>
Date:	Thu, 7 Jan 2016 22:35:26 +0300
From:	Konstantin Khlebnikov <koct9i@...il.com>
To:	Eric Dumazet <edumazet@...gle.com>
Cc:	Florian Westphal <fw@...len.de>,
	Thadeu Lima de Souza Cascardo <cascardo@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:54 PM, Eric Dumazet <edumazet@...gle.com> wrote:
> On Thu, Jan 7, 2016 at 7:04 AM, Konstantin Khlebnikov <koct9i@...il.com> wrote:
>> On Thu, Jan 7, 2016 at 2:59 PM, Eric Dumazet <edumazet@...gle.com> wrote:
>>> On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov <koct9i@...il.com> wrote:
>>>>
>>>> Also I've found strange thing: reason of expanding skb->cb from 40 to
>>>> 48 bypes in 2006
>>>> 3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
>>>> not fit. But it's is only 24 bytes. Does some arches add pad after
>>>> each _u16 field?
>>>
>>> "struct inet6_skb_parm" is part of struct tcp_skb_cb
>>>
>>> This is why Patrick had to increase skb->cb[]
>>
>> Whoa. Funny. TCP moves that chunk back and forward instead of just
>> putting it at the first place in struct.
>
> You probably want to look at git history to find out why it is done this way.
>
> TCP performance is critical for some of us, and doing such trick avoid
> one cache miss per skb in some critical list traversals.

Right. This way tcp stuff perfectly fits into leftovers of first cache line.
Then probably it's better to put ipv4/ipv6 cb into second line from
the beginning.