netdev - Re: [PATCH net-next 0/5] rocker: enable by default untagged VLAN support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 01 Jun 2015 17:01:10 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	sfeldma@...il.com
Cc:	netdev@...r.kernel.org, jiri@...nulli.us,
	simon.horman@...ronome.com
Subject: Re: [PATCH net-next 0/5] rocker: enable by default untagged VLAN
 support

From: sfeldma@...il.com
Date: Mon,  1 Jun 2015 11:39:01 -0700

> From: Scott Feldman <sfeldma@...il.com>
> 
> This patch set is a followup to Simon Horman's RFC patch:
> 
>    [PATCH/RFC net-next] rocker: by default accept untagged packets
> 
> Now, on port probe, we install untagged VLAN (vid=0) support for each port
> as the default.  This is equivalent to the command:
> 
>    bridge vlan add vid 0 dev DEV self
> 
> Accepting untagged VLAN pkts is a reasonable default, but the user could
> override this with:
> 
>    bridge vlan del vid 0 dev DEV self
> 
> With this, we no longer need 8021q module to install vid=0 when port interface
> opens.  In fact, we don't need support for legacy VLAN ndo ops at all since
> they're superseded by bridge_setlink/dellink.  So remove legacy VLAN ndo ops
> support in driver.  (The legacy VLAN ndo ops are supported by bonding/team
> drivers, but don't fit into the transaction model offered by switchdev, so
> switching all VLAN functions to bridge_setlink/dellink switchdev support gets
> us stacked driver + transaction model support).

Series applied, although I do have some trepidation about patch #5 since it
removes a capability that existed beforehand so someone might (well, they will)
get confused if they try to configure vlans that way and it no longer works.

If anyone else expresses similar objections I will probably have to
revert, just FYI.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html