From: Jiri Benc <jbenc@redhat.com>
To: Pravin Shelar <pshelar@ovn.org>
Cc: Jarno Rajahalme <jarno@ovn.org>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
Eric Garver <e@erig.me>
Subject: Re: [PATCH v3 net-next 3/3] openvswitch: Fix skb->protocol for vlan frames.
Date: Fri, 2 Dec 2016 10:42:02 +0100 [thread overview]
Message-ID: <20161202104202.426b2c80@griffin> (raw)
In-Reply-To: <CAOrHB_CAR8G=BF6X_+HgkRRnb=Erc6CYpCL4EnJfDRe7qBR2vg@mail.gmail.com>
On Thu, 1 Dec 2016 12:31:09 -0800, Pravin Shelar wrote:
> On Wed, Nov 30, 2016 at 6:30 AM, Jiri Benc <jbenc@redhat.com> wrote:
> > I'm not opposed to changing this but I'm afraid it needs much deeper
> > review. Because with this in place, no core kernel functions that
> > depend on skb->protocol may be called from within openvswitch.
> >
> Can you give specific example where it does not work?
I can't, I haven't reviewed the usage. I'm just saying that the stack
does not expect skb->protocol being ETH_P_8021Q for e.g. IPv4 packets.
It may not be relevant for the calls used by openvswitch but we should
be sure about that. Especially defragmentation and conntrack is worth
looking at.
Again, I'm not saying this is wrong nor that there is an actual
problem. I'm just pointing out that openvswitch has different
expectations about skb wrt. vlans than the rest of the kernel and we
should be reasonably sure the behavior is correct when passing between
the two.
> skb-protocol value is set by the caller, so it should not be
> arbitrary. is it missing in any case?
It's not set exactly by the caller, because that's what this patch is
removing. It is set by whoever handed over the packet to openvswitch.
The point is we don't know *what* it is set to. It may as well be
ETH_P_8021Q, breaking the conditions here. It should not happen in
practice but still, it seems weird to depend on the fact that the
packet coming to ovs has never skb->protocol equal to ETH_P_8021Q nor
ETH_P_8021AD.
Jiri
next prev parent reply other threads:[~2016-12-02 9:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 23:30 [PATCH v3 net-next 1/3] openvswitch: Add a missing break statement Jarno Rajahalme
2016-11-29 23:30 ` [PATCH v3 net-next 2/3] openvswitch: Use is_skb_forwardable() for length check Jarno Rajahalme
2016-11-30 7:23 ` Pravin Shelar
2016-11-30 13:51 ` Jiri Benc
2016-11-30 21:30 ` Jarno Rajahalme
2016-12-01 19:50 ` Pravin Shelar
2016-12-02 9:25 ` Jiri Benc
2016-12-05 0:22 ` Pravin Shelar
2016-12-08 20:50 ` Eric Garver
2016-12-09 8:49 ` Jiri Benc
2016-11-29 23:30 ` [PATCH v3 net-next 3/3] openvswitch: Fix skb->protocol for vlan frames Jarno Rajahalme
2016-11-30 7:34 ` Pravin Shelar
2016-11-30 14:30 ` Jiri Benc
2016-12-01 20:31 ` Pravin Shelar
2016-12-02 9:42 ` Jiri Benc [this message]
2016-12-02 9:49 ` Jiri Benc
2016-12-05 0:58 ` Pravin Shelar
2016-12-14 5:07 ` [PATCH v3 net-next 1/3] openvswitch: Add a missing break statement Pravin Shelar
2016-12-20 1:07 ` Jarno Rajahalme
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=20161202104202.426b2c80@griffin \
--to=jbenc@redhat.com \
--cc=e@erig.me \
--cc=jarno@ovn.org \
--cc=netdev@vger.kernel.org \
--cc=pshelar@ovn.org \
/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).