On Thu, 2015-12-03 at 16:54 -0800, Tom Herbert wrote: > On Thu, Dec 3, 2015 at 4:29 PM, Jeff Kirsher > <jeffrey.t.kirs...@intel.com> wrote: > > From: Jacob Keller <jacob.e.kel...@intel.com> > > > > The NVGRE protocol should be run over transparent ethernet bridge > > protocol, so we should verify this in our check whether the GRE > tunnel > > is NVGRE. While we're touching fm10k_main.c, update the copyright > year. > > > > Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com> > > Reviewed-by: Bruce Allan <bruce.w.al...@intel.com> > > Tested-by: Krishneil Singh <krishneil.k.si...@intel.com> > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com> > > --- > > drivers/net/ethernet/intel/fm10k/fm10k_main.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c > b/drivers/net/ethernet/intel/fm10k/fm10k_main.c > > index 746a198..c5f7e0d 100644 > > --- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c > > +++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c > > @@ -1,5 +1,5 @@ > > /* Intel Ethernet Switch Host Interface Driver > > - * Copyright(c) 2013 - 2014 Intel Corporation. > > + * Copyright(c) 2013 - 2015 Intel Corporation. > > * > > * This program is free software; you can redistribute it and/or > modify it > > * under the terms and conditions of the GNU General Public > License, > > @@ -708,6 +708,10 @@ static struct ethhdr > *fm10k_gre_is_nvgre(struct sk_buff *skb) > > if (nvgre_hdr->flags & FM10K_NVGRE_RESERVED0_FLAGS) > > return NULL; > > > > + /* verify protocol is transparent Ethernet bridging */ > > + if (nvgre_hdr->proto != htons(ETH_P_TEB)) > > + return NULL; > > + > > /* report start of ethernet header */ > > if (nvgre_hdr->flags & NVGRE_TNI) > > return (struct ethhdr *)(nvgre_hdr + 1); > > I don't understand this. Just because a packet is GRE with ETH_P_TEB > set and only using keyid does not make it a GRE packet. What happens > if someone creates a GRE tunnel on this same host with keyid and > starts sending packets on it? > > BTW, these is a potentially similar issue in fm10k_port_is_vxlan. > ndo_vxlan_port informs the driver of a vxlan port that may be > received > in a destination (presumably after the port has been bound for the > tunnel). This says _nothing_ about source ports or the destination > port. For instance, there is nothing that prevents an application > from > sending UDP packets to a "VXLAN port". If application does this, will > it's packets be messed up by the offload misinterpreting the packets > as VXLAN? > > As for this code: > > int hlen = ip_hdrlen(skb); > > /* currently only IPv4 is supported due to hlen above */ > > I'm just speechless ;-)
I was waiting for Jacob to respond, but I forgot he is on sabbatical now. I can drop this patch from the series until someone is able to address your questions/concerns.
signature.asc
Description: This is a digitally signed message part
