netdev - Re: [PATCH 0/4] skb paged fragment destructors

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: <20111222.143422.1948369460874203875.davem@davemloft.net>
Date:	Thu, 22 Dec 2011 14:34:22 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	mirqus@...il.com
Cc:	Ian.Campbell@...rix.com, eric.dumazet@...il.com,
	jesse.brandeburg@...el.com, netdev@...r.kernel.org
Subject: Re: [PATCH 0/4] skb paged fragment destructors

From: Michał Mirosław <mirqus@...il.com>
Date: Thu, 22 Dec 2011 20:29:30 +0100

> 2011/12/22 David Miller <davem@...emloft.net>:
>> From: Michał Mirosław <mirqus@...il.com>
>> Date: Thu, 22 Dec 2011 19:34:21 +0100
>>
>>> 2011/12/22 Ian Campbell <Ian.Campbell@...rix.com>:
>>>> On Wed, 2011-12-21 at 19:28 +0000, David Miller wrote:
>>>>> From: Eric Dumazet <eric.dumazet@...il.com>
>>>>> Date: Wed, 21 Dec 2011 15:02:18 +0100
>>>>> > No idea on this +2 point.
>>>>> I think I know, and I believe I instructed Alexey Kuznetsov to do
>>>>> this.
>>>>>
>>>>> When sendfile() is performed, we might start the SKB with the last few
>>>>> bytes of one page, and end the SKB with the first few bytes of another
>>>>> page.
>>>>>
>>>>> In order to fit a full 64K frame into an SKB in this situation we have
>>>>> to accomodate this case.
>>>> Thanks David, that makes sense.
>>>>
>>>> However I think you only actually need 1 extra page for that. If the
>>>> data in frag[0] starts at $offset then frag[16] will need to have
>>>> $offset bytes in it. e.g.
>>>>        4096-$offset + 4096*15 + $offset = 65536
>>>> which == 17 pages rather than 18.
>>>>
>>>> The following documents the status quo but I could update to switch to +
>>>> 1 instead if there are no flaws in the above logic...
>>>
>>> Since max IP datagram is 64K-1, adding ethernet and possibly VLAN
>>> headers makes the max size slightly above 64K and then you have
>>> 64K/PAGE_SIZE+2 pages appear in worst case.
>>
>> Headers go into the linear area, so they are not relevant for these
>> calculations.
> 
> Does this hold for LRO'ed packets and packets sent via PF_PACKET socket?

LRO is for receive, not packets we build on transmit, and in any event
have their headers also pulled into the linear area before the stack
sees it.

For PF_PACKET, in the packet_snd() case it uses a linear SKB and in
the tpacket_snd() case it uses a linear SKB as well.