netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Jiri Pirko <jiri@mellanox.com>,
	Alexander Duyck <aduyck@mirantis.com>,
	Eric Dumazet <edumazet@google.com>,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH net] net: avoid vlan ptype specific match to be leaked on real device
Date: Wed, 22 Jun 2016 14:21:29 +0200	[thread overview]
Message-ID: <1466598089.4707.31.camel@redhat.com> (raw)
In-Reply-To: <20160622105544.GC2068@nanopsycho.orion>

On Wed, 2016-06-22 at 12:55 +0200, Jiri Pirko wrote:
> Wed, Jun 22, 2016 at 12:25:15PM CEST, pabeni@redhat.com wrote:
> >Before the commit 0dfe17823945 ("net: vlan: goto another_round
> >instead of calling __netif_receive_skb"), on tagged skb ingress,
> >ptype specific protocol matches were delivered only to the
> >related vlan device, if any.
> >After said commit, jumping back to the 'another_round' label, allows
> >the later ptype specific check to match both orig_dev and skb->dev,
> >delivering the skb to both the vlan device and the underlying
> >device.
> >This cause i.e. packet sockets bound to a specific protocol type on
> >one of said devices to receive also frames really targeting the
> >other device.
> >This commit resets orig_dev before performing another round due to
> >vlan processing, allowing the skb to be delivered once again only
> >to the vlan specific ptypes.
> 
> I don't get why vlan should behave differently in this comparing to
> other stacked devices like bond/team/br etc.
> 
> Could you please explain?

vlan behavior has changed with the commit 0dfe17823945 (which is old,
but still...), this patch is trying to restore the old one.

The new behavior fouls existing applications which where expecting ptype
specific match to be delivered only on the relevant device. 

AFAIC jumping back to the 'another_round' is possible for team, bond,
macvlan, macsec and ipvlan device, beyond vlan devices. I think the
latter should be treated differently, beyond history reasons, because
the vlan device processing, stripping the vlan tag, actually changes the
ethernet type present into the ethernet header in respect to the wire
packet layout; strict match on that value should give different results
before and after vlan stripping.

Paolo

  reply	other threads:[~2016-06-22 12:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22 10:25 [PATCH net] net: avoid vlan ptype specific match to be leaked on real device Paolo Abeni
2016-06-22 10:55 ` Jiri Pirko
2016-06-22 12:21   ` Paolo Abeni [this message]
2016-06-22 12:40     ` Jiri Pirko
2016-06-26 20:06       ` David Miller
2016-06-27  9:28         ` Paolo Abeni
2016-06-27  9:37           ` Jiri Pirko
2016-06-27 13:43           ` 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=1466598089.4707.31.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=aduyck@mirantis.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jiri@mellanox.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.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).