From: Jiri Benc <jbenc@redhat.com>
To: Pravin Shelar <pshelar@nicira.com>
Cc: Jiri Pirko <jiri@resnulli.us>, netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Tom Herbert <therbert@google.com>,
Eric Dumazet <edumazet@google.com>,
Willem de Bruijn <willemb@google.com>,
Daniel Borkmann <dborkman@redhat.com>,
mst@redhat.com, fw@strlen.de, Paul.Durrant@citrix.com,
Thomas Graf <tgraf@suug.ch>, Cong Wang <cwang@twopensource.com>
Subject: Re: [patch net-next v4 8/9] net: move vlan pop/push functions into common code
Date: Fri, 21 Nov 2014 20:29:33 +0100 [thread overview]
Message-ID: <20141121202933.2970b7ea@griffin> (raw)
In-Reply-To: <CALnjE+p3PtaOz7Ujp7KDK0-=giP-kzEDDDvw8=GCjJdcECYJEA@mail.gmail.com>
On Fri, 21 Nov 2014 10:41:27 -0800, Pravin Shelar wrote:
> There is bug in the openvswitch code where vlan-pop does mac-length
> reset rather than subtracting VLAN_HLEN from mac-len. MPLS code
> depends on this. Now this patch moves the bug to common code. I am
> fine with this patch and I can send fix to change code vlan-pop code
> to adjust mac_len later on.
> But I am worried about the comment made by Jiri Benc on earlier
> version of this patch where is mentioned that subtracting VLAN_HLEN
> can break common case for vlan-pop. In that case we can not change
> this common function. Jiri Benc, Can you point me to the code, so the
> we can work on solution to fix this issue.
In such case, a skb that enters the __pop_vlan_tci function looks like
this:
+--------+--------+-------------+-----+---------+-------
| dstmac | srcmac | ETH_P_8021Q | tci | ETH_P_x | data
+--------+--------+-------------+-----+---------+-------
^ ^
mac_header network_header
skb->protocol = ETH_P_8021Q
skb->mac_len = 14
After the function finishes, it's supposed to look like this:
+--------+--------+---------+-------
| dstmac | srcmac | ETH_P_x | data
+--------+--------+---------+-------
^ ^
mac_header network_header
skb->protocol = ETH_P_x
skb->mac_len = 14
Blindly decrementing mac_len wouldn't work here, you'd end up with
mac_len = 10. You'd either need to ensure this case doesn't happen (it
does with openvswitch currently) or detect this case.
Jiri
--
Jiri Benc
next prev parent reply other threads:[~2014-11-21 19:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 13:04 [patch net-next v4 0/9] sched: introduce vlan action Jiri Pirko
2014-11-19 13:04 ` [patch net-next v4 1/9] openvswitch: actions: use skb_postpull_rcsum when possible Jiri Pirko
2014-11-20 1:52 ` Simon Horman
2014-11-19 13:04 ` [patch net-next v4 2/9] vlan: make __vlan_hwaccel_put_tag return void Jiri Pirko
2014-11-19 13:04 ` [patch net-next v4 3/9] vlan: kill vlan_put_tag helper Jiri Pirko
2014-11-19 13:04 ` [patch net-next v4 4/9] vlan: rename __vlan_put_tag to vlan_insert_tag_set_proto Jiri Pirko
2014-11-19 13:04 ` [patch net-next v4 5/9] vlan: introduce *vlan_hwaccel_push_inside helpers Jiri Pirko
2014-11-19 20:32 ` Pravin Shelar
2014-11-19 13:05 ` [patch net-next v4 6/9] vlan: introduce __vlan_insert_tag helper which does not free skb Jiri Pirko
2014-11-19 13:05 ` [patch net-next v4 7/9] net: move make_writable helper into common code Jiri Pirko
2014-11-19 13:05 ` [patch net-next v4 8/9] net: move vlan pop/push functions " Jiri Pirko
2014-11-21 16:11 ` Pravin Shelar
2014-11-21 18:05 ` Jiri Pirko
2014-11-21 18:41 ` Pravin Shelar
2014-11-21 19:08 ` Jiri Pirko
2014-11-21 19:29 ` Jiri Benc [this message]
2014-12-04 0:33 ` Pravin Shelar
2014-12-04 16:57 ` Jiri Benc
2014-11-19 13:05 ` [patch net-next v4 9/9] sched: introduce vlan action Jiri Pirko
2014-11-19 13:08 ` [patch iproute2 v4] tc: add support for vlan tc action Jiri Pirko
2014-11-21 11:31 ` [patch iproute2 v4.1] " Jiri Pirko
2014-12-03 17:35 ` [patch iproute2 v4] " Stephen Hemminger
2014-11-21 19:21 ` [patch net-next v4 0/9] sched: introduce vlan action David Miller
2014-11-21 23:52 ` Jiri Pirko
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=20141121202933.2970b7ea@griffin \
--to=jbenc@redhat.com \
--cc=Paul.Durrant@citrix.com \
--cc=cwang@twopensource.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pshelar@nicira.com \
--cc=tgraf@suug.ch \
--cc=therbert@google.com \
--cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).