From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Tom Herbert <tom@herbertland.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Jacob Keller <jacob.e.keller@intel.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com
Subject: Re: [net-next 10/17] fm10k: add TEB check to fm10k_gre_is_nvgre
Date: Fri, 04 Dec 2015 15:03:19 -0800 [thread overview]
Message-ID: <1449270199.3224.89.camel@intel.com> (raw)
In-Reply-To: <CALx6S35nF58aS1hR1MVtNQ8Y1iv5zt-OzMT_2dXSA5ysqPD7yw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]
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.kirsher@intel.com> wrote:
> > From: Jacob Keller <jacob.e.keller@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.keller@intel.com>
> > Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
> > Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-12-04 23:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 0:29 [net-next 00/17][pull request] 100GbE Intel Wired LAN Driver Updates 2015-12-03 Jeff Kirsher
2015-12-04 0:29 ` [net-next 01/17] fm10k: Fix error handling in the function fm10k_setup_tc for certain function calls Jeff Kirsher
2015-12-04 0:41 ` Joe Perches
2015-12-04 0:29 ` [net-next 02/17] fm10k: set netdev features in one location Jeff Kirsher
2015-12-04 0:29 ` [net-next 03/17] fm10k: reset max_queues on init_hw_vf failure Jeff Kirsher
2015-12-04 0:29 ` [net-next 04/17] fm10k: always check init_hw for errors Jeff Kirsher
2015-12-04 0:29 ` [net-next 05/17] fm10k: reinitialize queuing scheme after calling init_hw Jeff Kirsher
2015-12-04 0:29 ` [net-next 06/17] fm10k: Correct typecast in fm10k_update_xc_addr_pf Jeff Kirsher
2015-12-04 0:29 ` [net-next 07/17] fm10k: explicitly typecast vlan values to u16 Jeff Kirsher
2015-12-04 0:29 ` [net-next 08/17] fm10k: add statistics for actual DWORD count of mbmem mailbox Jeff Kirsher
2015-12-04 0:29 ` [net-next 09/17] fm10k: rename mbx_tx_oversized statistic to mbx_tx_dropped Jeff Kirsher
2015-12-04 0:29 ` [net-next 10/17] fm10k: add TEB check to fm10k_gre_is_nvgre Jeff Kirsher
2015-12-04 0:54 ` Tom Herbert
2015-12-04 23:03 ` Jeff Kirsher [this message]
2015-12-04 0:29 ` [net-next 11/17] fm10k: Add support for ITR scaling based on PCIe link speed Jeff Kirsher
2015-12-04 0:29 ` [net-next 12/17] fm10k: introduce ITR_IS_ADAPTIVE macro Jeff Kirsher
2015-12-04 0:29 ` [net-next 13/17] fm10k: Update adaptive ITR algorithm Jeff Kirsher
2015-12-04 0:29 ` [net-next 14/17] fm10k: use macro for default Tx and Rx ITR values Jeff Kirsher
2015-12-04 0:29 ` [net-next 15/17] fm10k: change default Tx ITR to 25usec Jeff Kirsher
2015-12-04 0:29 ` [net-next 16/17] fm10k: TRIVIAL fix typo of hardware Jeff Kirsher
2015-12-04 0:29 ` [net-next 17/17] fm10k: TRIVIAL cleanup order at top of fm10k_xmit_frame Jeff Kirsher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1449270199.3224.89.camel@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=davem@davemloft.net \
--cc=jacob.e.keller@intel.com \
--cc=jogreene@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=sassmann@redhat.com \
--cc=tom@herbertland.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.