From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: Eli Cooper <elicooper@gmx.com>
Cc: Tom Herbert <tom@herbertland.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH v2] ip6_tunnel: Clear IP6CB in ip6_tnl_xmit() after encapsulation
Date: Fri, 28 Oct 2016 19:07:57 +0300 [thread overview]
Message-ID: <20161028190757.26be756c@halley> (raw)
In-Reply-To: <9a1bb72b-246d-021a-236c-f523832964ac@gmx.com>
Hi,
On Fri, 28 Oct 2016 13:13:45 +0800 Eli Cooper <elicooper@gmx.com> wrote:
> So I think it is best that all the
> IP6CB gets cleared before it is pushed to the next layer.
Just a comparison to the ipv4 world:
All tunnels (udp/ip based) end up calling iptunnel_xmit(), which:
- scrubs the skb
- clears any IPCB residues
- installs the iphdr
- invokes ip_local_out()
OTOH ip6_tnl_xmit:
- scrubs the skb
- installs the ipv6hdr
- invokes ip6tunnel_xmit() - a thin wrapper to ip6_local_out()
* missing: clearing cb
And OTOH udp_tunnel6_xmit_skb:
- clears IPCB(skb)->opt and some IPCB(skb)->flags
(why these 2 explicitly? and why at this point? and IPCB is no longer
relevant...)
- installs the ipv6hdr
- invokes ip6tunnel_xmit() - a thin wrapper to ip6_local_out()
* missing: scrub, clearing cb
> Maybe we
> should clear IP6CB in ip6tunnel_xmit(), rather than in every tunnel's codes?
This seems reasonable.
A potential issue might be whether it needs to be done earlier, although
I've reviewed current versions of both 'ip6_tnl_xmit' and
'udp_tunnel6_xmit_skb' and it looks okay. But please verify.
> By the way, I don't see any point in setting IPCB(skb)->flags in
> udp_tunnel6_xmit_skb(). It will not be interpreted as IPCB any further
> past ip6tunnel_xmit(), even if it were not cleared. Plus, nothing seems
> to use these flags anyway.
This seems right.
It was introduced in 6a93cc9052 "udp-tunnel: Add a few more UDP tunnel APIs".
If you checkout that tree, you'll notice same treatment to
IPCB(skb)->opt and IPCB(skb)->flags in l2tp_xmit_skb... maybe it was
just copied ;-)
Best,
Shmulik
next prev parent reply other threads:[~2016-10-28 16:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-28 1:52 [PATCH v2] ip6_tunnel: Clear IP6CB in ip6_tnl_xmit() after encapsulation Eli Cooper
2016-10-28 2:17 ` Tom Herbert
2016-10-28 5:13 ` Eli Cooper
2016-10-28 16:07 ` Shmulik Ladkani [this message]
2016-10-31 18:18 ` 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=20161028190757.26be756c@halley \
--to=shmulik.ladkani@gmail.com \
--cc=davem@davemloft.net \
--cc=elicooper@gmx.com \
--cc=netdev@vger.kernel.org \
--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.