netdev - Re: LRO/GSO interaction when packets are forwarded

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1204909575.4220.71.camel@moonstone.uk.level5networks.com>
Date:	Fri, 07 Mar 2008 17:06:15 +0000
From:	Kieran Mansley <kmansley@...arflare.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	netdev@...r.kernel.org
Subject: Re: LRO/GSO interaction when packets are forwarded

On Fri, 2008-03-07 at 08:25 -0800, Stephen Hemminger wrote:
> On Fri, 07 Mar 2008 14:09:57 +0000
> Kieran Mansley <kmansley@...arflare.com> wrote:
> 
> > We've seen a couple of problems when using a bridge or IP forwarding
> > combined with LRO packets generated by a network device driver.  As you
> > know, LRO packets can be either be page based (and passed up with
> > lro_receive_page()) or use the skb frag_list (and passed up with
> > lro_receive_skb()).  In both cases it is likely that the device driver
> > will have set CHECKSUM_UNNECESSARY to indicate that the packet has been
> > checksummed by the device, and gso_size to mark it as an LRO packet and
> > indicate the actual received MSS.
> 
> First off, no hardware should ever do LRO on non-local packets. If the
> hardware isn't smart enough to do this, I guess the bridge code to have
> an API to turn it off. IP should also turn it off if ip_forwarding
> is enabled on that device.

If the only way to deal with this is to prevent LRO in those cases,
having an API to turn if off would clearly be helpful: working out in
the hardware or driver which packets can be forwarded or not is hard,
and would probably be a layering violation in itself.  

However, if there were a way in which it could be made to work, that
would in many ways be preferable.

> > If this skb goes directly to the network stack everything is fine.  The
> > problem comes when this packet instead goes into a bridge and is then
> > retransmitted on another device.  The skb seems to pass through the
> > bridge relatively unmodified and because it has gso_size set the
> > transmit path will attempt to segment it.  If page-based allocation has
> > been used, this is fine, but if the skb frag_list has been used the
> > transmit path BUGs in skb_gso_segment():
> 
> You can't do LRO with bridging, it is that simple, it is a protocol
> layering violation.

Agreed.  LRO is a layering violation with or without bridging.  If the
consensus is that LRO with bridging is not viable, then that's
straightforward for us, but there are a lot of people who will want this
for performance.  Bridging and virtualisation are common partners, and
virtualisation and high performance networking are also rather popular
at the moment.  

Given that there seem to be a small number of places where this is
currently causing problems (LRO through a bridge to a stack is fine,
it's only if the packet is forwarded that things go wrong), and that an
LRO packet should in most cases be very easy to segment (it's already in
network-sized fragments) I wonder if making it work would be
easier/better than preventing it from happening.

Kieran

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html