| Message ID | 1396623382.15118.6.camel@dcbw.local |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Dan Williams <dcbw@redhat.com> Date: Fri, 04 Apr 2014 09:56:22 -0500 > 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@redhat.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. Unfortunately I think we're stuck with the existing behavior. And since, as you say, iproute2 always does the removal when the device is up, the behavior you desire is available. -- 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
On Fri, 2014-04-04 at 11:08 -0400, David Miller wrote: > From: Dan Williams <dcbw@redhat.com> > Date: Fri, 04 Apr 2014 09:56:22 -0500 > > > 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@redhat.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. > > Unfortunately I think we're stuck with the existing behavior. Ok, fair enough. Dan -- 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
On Fri, 04 Apr 2014 10:15:50 -0500 Dan Williams <dcbw@redhat.com> wrote: > On Fri, 2014-04-04 at 11:08 -0400, David Miller wrote: > > From: Dan Williams <dcbw@redhat.com> > > Date: Fri, 04 Apr 2014 09:56:22 -0500 > > > > > 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@redhat.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. > > > > Unfortunately I think we're stuck with the existing behavior. > > Ok, fair enough. > > Dan > > That is the way it has been all the way back to 2.4. -- 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
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; }
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@redhat.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. -- 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