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
| ||
|
Message-ID: <54525A00.6070303@redhat.com> Date: Thu, 30 Oct 2014 08:32:16 -0700 From: Alexander Duyck <alexander.h.duyck@...hat.com> To: Tom Herbert <therbert@...gle.com> CC: Neal Cardwell <ncardwell@...gle.com>, Pravin Shelar <pshelar@...ira.com>, Alexander Duyck <alexander.duyck@...il.com>, netdev <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>, "H.K. Jerry Chu" <hkchu@...gle.com>, Eric Dumazet <edumazet@...gle.com> Subject: Re: [PATCH net] gre: Fix regression in gretap TSO support On 10/30/2014 08:05 AM, Tom Herbert wrote: > On Thu, Oct 30, 2014 at 7:30 AM, Alexander Duyck > <alexander.h.duyck@...hat.com> wrote: >> On 10/30/2014 06:51 AM, Neal Cardwell wrote: >>> On Thu, Oct 30, 2014 at 1:14 AM, Pravin Shelar <pshelar@...ira.com> wrote: >>>> On Wed, Oct 29, 2014 at 8:26 PM, <alexander.duyck@...il.com> wrote: >>>>> From: Alexander Duyck <alexander.h.duyck@...hat.com> >>>>> >>>>> On recent kernels I found that TSO on gretap interfaces didn't work. >>>>> After >>>>> bisecting it I found that commit b884b1a4 had introduced a regression in >>>>> which the Ethernet header was being included in the GRE header length. >>>>> >>>>> This change corrects that by basing the GRE header length on the inner >>>>> mac >>>>> header in the case of GRE tunnels using transparent Ethernet bridging, >>>>> and >>>>> uses the network header for all other GRE tunnel types. >>>>> >>>>> Fixes: b884b1a4 ("gre_offload: simplify GRE header length calculation in >>>>> gre_gso_segment()") >>> Hmm. There may be other protocols, either now or in the future, where >>> we want to be able to have a mac header inside the GRE header, rather >>> than a network header. AFAICT it would be safer to revert b884b1a4, >>> and go back to the previous code (from c50cd357), where we parse the >>> GRE header to figure out its length. >>> >>> neal >> >> The change is consistent with how we handle this in other spots throughout >> the kernel. If nothing else you can just search for ETH_P_TEB and you will >> find multiple spots in the kernel where IP tunnels differentiate between >> transparent Ethernet bridging and regular IP in IP tunnels by checking for >> the protocol ETH_P_TEB. >> > I'm not sure I understand this. We always use inner mac header in > __skb_udp_tunnel_segment for computing tunnel length and don't > distinguish between Ethernet or IP encapsulation. Presumably, in the > case of IP encapsulation inner mac header is equal to inner network > header. Why is this different for GRE? > > Thanks, > Tom I'll dig into that a bit more and see if I can simplify this. I just wasn't sure if the inner mac header was being initialized or not in the case of IP in IP tunnels. Thanks, Alex -- 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
Powered by blists - more mailing lists