netdev - Re: [RFC PATCH] gro: Partly revert "net: gro: allow to build full sized skb"

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: <20160422091328.GK3347@gauss.secunet.com>
Date:	Fri, 22 Apr 2016 11:13:28 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Sowmini Varadhan <sowmini.varadhan@...cle.com>,
	<netdev@...r.kernel.org>
Subject: Re: [RFC PATCH] gro: Partly revert "net: gro: allow to build full
 sized skb"

On Thu, Apr 21, 2016 at 05:59:06AM -0700, Eric Dumazet wrote:
> On Thu, 2016-04-21 at 09:40 +0200, Steffen Klassert wrote:
> > 
> > Hi Eric, this is a followup on our discussion at the netdev
> > conference. Would you still be ok with this revert, or do
> > you think there is a better solution in sight?
> 
> Note that some GRO enabled drivers would still generate frag_list.
> 
> (This happens if they are using skb with some TCP payload in skb->head
> and skb->head was allocated with kmalloc())
> 
> We have sysctl_max_skb_frags sysctl, we might have a sysctl
> enabling/disabling GRO from building any frag_list.
> Or simply reuse an existing one, like /proc/sys/net/ipv4/ip_forward ?)

Reusing the ipv4/ipv6 forwarding sysctls would be probably the
simplest solution, but maybe we can do the partial split in
the GSO layer that Alex proposed. Then we would not need to
change the way GRO builds the buffers.

> 
> Here at Google, we increased MAX_SKB_FRAGS, but this is a rather
> intrusive change to be upstreamed :(

I've played here with MAX_SKB_FRAGS too, but it seems to
be device specific how many page fragments it can handle.
I wonder if we could increase MAX_SKB_FRAGS at the GRO
layer and let GSO split this buffer in something that
the transmitting device can handle?