[patch net] vlan: fix bond/team enslave of vlan challenged slave/port

In vlan_uses_dev() check for number of vlan devs rather than existence
of vlan_info. The reason is that vlan id 0 is there without appropriate
vlan dev on it by default which prevented from enslaving vlan challenged
dev.

Reported-by: Jon Stanley <redacted>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
 drivers/net/bonding/bond_main.c | 2 +-
 net/8021q/vlan_core.c           | 9 ++++++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b721902..b2530b0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c

@@ -1519,7 +1519,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
 	/* no need to lock since we're protected by rtnl_lock */
 	if (slave_dev->features & NETIF_F_VLAN_CHALLENGED) {
 		pr_debug("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name);
-		if (bond_vlan_used(bond)) {
+		if (vlan_uses_dev(bond_dev)) {
 			pr_err("%s: Error: cannot enslave VLAN challenged slave %s on VLAN enabled bond %s\n",
 			       bond_dev->name, slave_dev->name, bond_dev->name);
 			return -EPERM;

diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index fbbf1fa..65e06ab 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c

@@ -366,6 +366,13 @@ EXPORT_SYMBOL(vlan_vids_del_by_dev);
 
 bool vlan_uses_dev(const struct net_device *dev)
 {
-	return rtnl_dereference(dev->vlan_info) ? true : false;
+	struct vlan_info *vlan_info;
+
+	ASSERT_RTNL();
+
+	vlan_info = rtnl_dereference(dev->vlan_info);
+	if (!vlan_info)
+		return false;
+	return vlan_info->grp.nr_vlan_devs ? true : false;
 }
 EXPORT_SYMBOL(vlan_uses_dev);

-- 
1.7.11.4

On Sun, Oct 14, 2012 at 10:30 AM, Jiri Pirko [off-list ref] wrote:

In vlan_uses_dev() check for number of vlan devs rather than existence
of vlan_info. The reason is that vlan id 0 is there without appropriate
vlan dev on it by default which prevented from enslaving vlan challenged
dev.

Thanks for the patch!

However, I'm now running into a new issue. Note that I've backported
this to an older kernel (3.3.2, eww), but I don't *think* that matters
for this. Now I'm getting a "refused to change device type" which
looks like it comes from around here:

                        res = netdev_bonding_change(bond_dev,
                                                    NETDEV_PRE_TYPE_CHANGE);
                        res = notifier_to_errno(res);
                        if (res) {
                                pr_err("%s: refused to change device type\n",
                                       bond_dev->name);

I'm not quite smart enough to figure out what's going on here. FWIW,
looking back in history it looks like the only relevant change from
here to mainline is the replacement of netdev_bonding_change() with
direct calls to call_netdevice_notifiers().

Again, .let me know if more info is needed, and thanks for the quick response!

On Mon, Oct 15, 2012 at 10:53 AM, Jon Stanley [off-list ref] wrote:

However, I'm now running into a new issue. Note that I've backported
this to an older kernel (3.3.2, eww)

My bad, I tried this on mainline and it works fine. Any pointers on
what needs to get backported into 3.3 before I go pulling my hair out
over it? :)

Mon, Oct 15, 2012 at 10:38:44PM CEST, jstanley@rmrf.net wrote:

On Mon, Oct 15, 2012 at 10:53 AM, Jon Stanley [off-list ref] wrote:

quoted

However, I'm now running into a new issue. Note that I've backported
this to an older kernel (3.3.2, eww)

My bad, I tried this on mainline and it works fine. Any pointers on
what needs to get backported into 3.3 before I go pulling my hair out
over it? :)

I can't think about anything atm. Happy hair pulling :)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Jiri Pirko <jiri@resnulli.us>
Date: Sun, 14 Oct 2012 16:30:56 +0200

In vlan_uses_dev() check for number of vlan devs rather than existence
of vlan_info. The reason is that vlan id 0 is there without appropriate
vlan dev on it by default which prevented from enslaving vlan challenged
dev.

Reported-by: Jon Stanley <redacted>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>

Applied and queued up for -stable, thanks.