All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Jesse Gross <jesse@nicira.com>
Cc: netdev <netdev@vger.kernel.org>,
	Pravin B Shelar <pshelar@nicira.com>,
	Jiri Benc <jbenc@redhat.com>, David Miller <davem@davemloft.net>
Subject: Re: [RFT v3] geneve: implement support for IPv6-based tunnels
Date: Thu, 1 Oct 2015 16:03:56 -0400	[thread overview]
Message-ID: <20151001200355.GF3086@tuxdriver.com> (raw)
In-Reply-To: <CAEP_g=9g=Bt09+Kf9CWaSuhPFhUVXcesW28ksq+8b5hQwzf6Vw@mail.gmail.com>

On Thu, Oct 01, 2015 at 09:26:59AM -0700, Jesse Gross wrote:
> On Wed, Sep 30, 2015 at 11:34 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> > index 8f5c02eed47d..291d3d7754a8 100644
> > --- a/drivers/net/geneve.c
> > +++ b/drivers/net/geneve.c
> > +#define GENEVE_F_IPV6          0x00000001
> 
> I wasn't sure why we needed this flag. Can't we just look at the
> remote address family?

Yeah, I had grander plans... :-)  I think it can be removed.

> > -static void geneve_sock_release(struct geneve_sock *gs)
> > +static void __geneve_sock_release(struct geneve_sock *gs)
> >  {
> >         if (--gs->refcnt)
> >                 return;
> 
> Do we need a check for NULL first here?

Sure.

> > +#if IS_ENABLED(CONFIG_IPV6)
> > +static int geneve6_build_skb(struct dst_entry *dst, struct sk_buff *skb,
> > +                            __be16 tun_flags, u8 vni[3], u8 opt_len, u8 *opt,
> > +                            bool csum, bool xnet)
> > +{
> > +       struct genevehdr *gnvh;
> > +       int min_headroom;
> > +       int err;
> > +
> > +       skb_scrub_packet(skb, xnet);
> 
> Is there a reason why this applies to only IPv6? It seems like it
> would be common

The dst vs rt thing was the motivator.  It probably could be refactored
to share some code between geneve_build_skb and geneve6_build_skb.

> > +static struct dst_entry *geneve_get_dst(struct sk_buff *skb,
> 
> It might be worth clarifying this name - it wasn't immediately obvious
> to me the difference between geneve_get_rt() and geneve_get_dst() is
> IPv4 vs. IPv6.

geneve_get_v4_rt and geneve_get_v6_dst?

> > +#if IS_ENABLED(CONFIG_IPV6)
> > +static netdev_tx_t geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
> > +                                   struct ip_tunnel_info *info)
> [...]
> > +       dst = geneve_get_dst(skb, dev, &fl6, info);
> > +       if (IS_ERR(dst)) {
> > +               netdev_dbg(dev, "no route to %pI6\n", &fl6.daddr);
> > +               dev->stats.tx_carrier_errors++;
> > +               goto tx_error;
> > +       }
> 
> It looks like we double log/count this error (although this also
> appears to be a problem for IPv4).

Indeed.  I'll try to fix/refactor that a bit...

> > +       err = udp_tunnel6_xmit_skb(dst, gs6->sock->sk, skb, dev,
> > +                                  &fl6.saddr, &fl6.daddr, 0, ttl,
> > +                                  sport, geneve->dst_port, !udp_csum);
> 
> It seems like TOS is not handled here?

There is no tos parameter for udp_tunnel6_xmit_skb.  Is there some
other way to inject it?  Is there a mapping to priority (i.e. the
0 parameter)?

> > @@ -823,9 +1095,11 @@ static int geneve_configure(struct net *net, struct net_device *dev,
> >         int err;
> >
> >         if (metadata) {
> > -               if (rem_addr || vni || tos || ttl)
> > +               if (remote != &geneve_remote_unspec || vni || tos || ttl)
> >                         return -EINVAL;
> 
> I think this will fail in the non-compat metadata case. The remote
> that is passed in will be a zeroed copy on the stack, so the address
> won't match the static version. I believe the check should be for
> AF_UNSPEC instead.

It is actually checking the pointer value against the address of
that static data structure, which is only reference through the
geneve_dev_create_fb path to calling geneve_configure.  Knowing that
are you still troubled by it?

John

P.S. I may not respond/repost for a while due to some travel during
the next week...
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

  reply	other threads:[~2015-10-01 20:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-24 18:34 [RFT] geneve: implement support for IPv6-based tunnels John W. Linville
2015-09-24 18:39 ` [PATCH iproute2] geneve: add support for IPv6 link partners John W. Linville
2015-11-24  0:23   ` Stephen Hemminger
2015-09-25 12:08 ` [RFT] geneve: implement support for IPv6-based tunnels Jiri Benc
2015-09-28 19:20   ` John W. Linville
2015-09-29 16:10     ` Jiri Benc
2015-09-30 17:04 ` [RFT v2] " John W. Linville
2015-09-30 18:07   ` kbuild test robot
2015-09-30 18:34   ` [RFT v3] " John W. Linville
2015-10-01  1:55     ` kbuild test robot
2015-10-01 15:38     ` Jiri Benc
2015-10-01 16:26     ` Jesse Gross
2015-10-01 20:03       ` John W. Linville [this message]
2015-10-01 21:07         ` Jesse Gross
2015-10-20 15:11     ` [PATCH v4 1/2] " John W. Linville
2015-10-20 15:11       ` [PATCH 2/2] geneve: handle ipv6 priority like ipv4 tos John W. Linville
2015-10-21  5:13         ` Jesse Gross
2015-10-20 22:55       ` [PATCH v4 1/2] geneve: implement support for IPv6-based tunnels kbuild test robot
2015-10-21  1:52       ` YOSHIFUJI Hideaki/吉藤英明
2015-10-21 18:58         ` John W. Linville
2015-10-21  5:06       ` Jesse Gross
2015-10-22 19:45       ` [PATCH v5 " John W. Linville
2015-10-22 19:45         ` [PATCH v5 2/2] geneve: handle ipv6 priority like ipv4 tos John W. Linville
2015-10-23  4:48         ` [PATCH v5 1/2] geneve: implement support for IPv6-based tunnels YOSHIFUJI Hideaki
2015-10-23 13:38           ` John W. Linville
2015-10-23 14:40         ` [PATCH v6 " John W. Linville
2015-10-23 14:40           ` [PATCH v6 2/2] geneve: handle ipv6 priority like ipv4 tos John W. Linville
2015-10-26  4:08           ` [PATCH v6 1/2] geneve: implement support for IPv6-based tunnels Jesse Gross
2015-10-26 21:01           ` [PATCH v7 1/3] " John W. Linville
2015-10-26 21:01             ` [PATCH v7 2/3] geneve: handle ipv6 priority like ipv4 tos John W. Linville
2015-10-30  3:11               ` David Miller
2015-10-26 21:01             ` [PATCH v7 3/3] geneve: add IPv6 bits to geneve_fill_metadata_dst John W. Linville
2015-10-27 12:48               ` Sergei Shtylyov
2015-10-27 13:49               ` [PATCH v8 " John W. Linville
2015-10-27 14:24                 ` Jesse Gross
2015-10-30  3:12                 ` David Miller
2015-10-30  3:11             ` [PATCH v7 1/3] geneve: implement support for IPv6-based tunnels David Miller

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=20151001200355.GF3086@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=davem@davemloft.net \
    --cc=jbenc@redhat.com \
    --cc=jesse@nicira.com \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@nicira.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.