netdev - [RFC PATCH] bridge: remove !IFF_UP restriction when deleting bridge from ioctl

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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Date:	Fri, 04 Apr 2014 09:56:22 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	netdev@...r.kernel.org
Subject: [RFC PATCH] bridge: remove !IFF_UP restriction when deleting bridge
 from ioctl

netlink doesn't care about IFF_UP when deleting a bridge, so "ip link
del br0" works just fine.  The ioctl does care, which means that brctl
complains "bridge br0 still up; can't delete it".  Make things
consistent by always allowing bridge deletion even if the bridge is up.

Signed-off-by: Dan Williams <dcbw@...hat.com>
---
Question: does anyone consider the ioctl behavior API?  Can we change it
even though it's been this way forever?  It means that bridges that
previously would not have been deleted by brctl will now be deleted.
But anyone using /sbin/ip could already delete them.

diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 54d207d..33cd83f 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -264,19 +264,14 @@ int br_del_bridge(struct net *net, const char *name)
 		ret =  -ENXIO; 	/* Could not find device */
 
 	else if (!(dev->priv_flags & IFF_EBRIDGE)) {
 		/* Attempt to delete non bridge device! */
 		ret = -EPERM;
 	}
 
-	else if (dev->flags & IFF_UP) {
-		/* Not shutdown yet. */
-		ret = -EBUSY;
-	}
-
 	else
 		br_dev_delete(dev, NULL);
 
 	rtnl_unlock();
 	return ret;
 }
 

--
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