From patchwork Mon Mar 3 22:47:03 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Luis R. Rodriguez" X-Patchwork-Id: 326084 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id B66962C007E for ; Tue, 4 Mar 2014 09:49:04 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755698AbaCCWrf (ORCPT ); Mon, 3 Mar 2014 17:47:35 -0500 Received: from mail-pd0-f174.google.com ([209.85.192.174]:58151 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755679AbaCCWrd (ORCPT ); Mon, 3 Mar 2014 17:47:33 -0500 Received: by mail-pd0-f174.google.com with SMTP id y13so4303340pdi.33 for ; Mon, 03 Mar 2014 14:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=sa0oFH1OlWwRRd9Hr72Mvag/WbPY5J7EwK3xXl51pFs=; b=sI7XD8e3pPOP3DsthwM3AeBzBV5iOpwzKKrJcob9FYjfHAAV51uUKMCl58zamyzyFO zcd5Ewe25AYe/L2hrg/tMC6rTXrEM8aku/Ulu2c66aEQ2tnLlYSlWhXlrPI+CTI1cpqn 7RfYl4TCaFgFGRhuF13aJ+eveP6mFGOgjX2fF1LTySGsbfCR4a36TpOnyhNh3jLKQNLK gPEsQD4wiwvd+YgCNZFiUqUqeST3B5hE5cZnxzU3/N9s2RImapirQdRUrrQgxCrMI89O ncyQMG92+dGTsOMB8WMEl+idZ+wp7SpQbdO0+ImoGjNbjcApkpOMw7oBNXKrxF12gHlA 1Bag== X-Received: by 10.68.237.99 with SMTP id vb3mr22027711pbc.76.1393886852814; Mon, 03 Mar 2014 14:47:32 -0800 (PST) Received: from mcgrof@gmail.com (c-24-7-61-223.hsd1.ca.comcast.net. [24.7.61.223]) by mx.google.com with ESMTPSA id yx3sm13460604pbb.6.2014.03.03.14.47.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 14:47:31 -0800 (PST) Received: by mcgrof@gmail.com (sSMTP sendmail emulation); Mon, 03 Mar 2014 14:47:28 -0800 From: "Luis R. Rodriguez" To: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, mcgrof@suse.com, Stephen Hemminger , bridge@lists.linux-foundation.org Subject: [RFC v3 4/6] bridge: enable root block during device registration Date: Mon, 3 Mar 2014 14:47:03 -0800 Message-Id: <1393886825-24323-5-git-send-email-mcgrof@do-not-panic.com> X-Mailer: git-send-email 1.8.5.3 In-Reply-To: <1393886825-24323-1-git-send-email-mcgrof@do-not-panic.com> References: <1393886825-24323-1-git-send-email-mcgrof@do-not-panic.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: "Luis R. Rodriguez" root block support was added via 1007dd1a on v3.8 but toggling this flag is only allowed after a device has been registered and added to a bridge as its a bridge *port* primitive, not a *net_device* feature. There are work arounds possible to account for the lack of netlink tools to toggle root_block, such as using the root_block syfs attribute [0] or using udev / the driver to set the MAC address to something high such as FE:FF:FF:FF:FF:FF, but neither of these ensure root block is respected _from_the_start_ through device initialization. In order to support the root_block feature from the start since device initialization and in order to avoid having to require userspace work arounds to existing deployments this exposes a private net_device flag which enables drivers that know they want to start with the root_block feature enabled form the start. The only caveat with this is topologies that require STP or non-root will either have to use sysfs [0] or netlink tools like the iproute2 bridge util to toggle the flag off after initialization. This is an accepted compromise. This flag is required given that ndo_add_slave() currently does not allow specifying any other parameters other than the net_device. We could extend this but in order to do that properly we'd need to evaluate all other types of master device implementations. [0] echo 1 > /sys/devices/vif-2-0/net/vif2.0/brport/root_block Cc: Stephen Hemminger Cc: bridge@lists.linux-foundation.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Cc: kvm@vger.kernel.org Signed-off-by: Luis R. Rodriguez --- include/linux/netdevice.h | 7 +++++++ net/bridge/br_if.c | 2 ++ 2 files changed, 9 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 1a86948..b17643a 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -1181,6 +1181,11 @@ struct net_device_ops { * @IFF_LIVE_ADDR_CHANGE: device supports hardware address * change when it's running * @IFF_MACVLAN: Macvlan device + * @IFF_BRIDGE_ROOT_BLOCK: don't consider this net_device for root port + * when this interface is added to a bridge. This makes use of the + * root_block mechanism but since its a bridge port primitive this + * flag can be used to instantiate the preference to have root block + * enabled from the start since initialization. */ enum netdev_priv_flags { IFF_802_1Q_VLAN = 1<<0, @@ -1205,6 +1210,7 @@ enum netdev_priv_flags { IFF_SUPP_NOFCS = 1<<19, IFF_LIVE_ADDR_CHANGE = 1<<20, IFF_MACVLAN = 1<<21, + IFF_BRIDGE_ROOT_BLOCK = 1<<22, }; #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN @@ -1229,6 +1235,7 @@ enum netdev_priv_flags { #define IFF_SUPP_NOFCS IFF_SUPP_NOFCS #define IFF_LIVE_ADDR_CHANGE IFF_LIVE_ADDR_CHANGE #define IFF_MACVLAN IFF_MACVLAN +#define IFF_BRIDGE_ROOT_BLOCK IFF_BRIDGE_ROOT_BLOCK /* * The DEVICE structure. diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c index 54d207d..4bee748 100644 --- a/net/bridge/br_if.c +++ b/net/bridge/br_if.c @@ -228,6 +228,8 @@ static struct net_bridge_port *new_nbp(struct net_bridge *br, br_init_port(p); p->state = BR_STATE_DISABLED; br_stp_port_timer_init(p); + if (dev->priv_flags & IFF_BRIDGE_ROOT_BLOCK) + p->flags |= BR_ROOT_BLOCK; br_multicast_add_port(p); return p;