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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ