From patchwork Mon Mar 3 22:46:59 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: 326088 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 2CBA62C00AB for ; Tue, 4 Mar 2014 09:50:26 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755545AbaCCWrQ (ORCPT ); Mon, 3 Mar 2014 17:47:16 -0500 Received: from mail-pb0-f47.google.com ([209.85.160.47]:38126 "EHLO mail-pb0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753236AbaCCWrO (ORCPT ); Mon, 3 Mar 2014 17:47:14 -0500 Received: by mail-pb0-f47.google.com with SMTP id up15so4318140pbc.6 for ; Mon, 03 Mar 2014 14:47:14 -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; bh=kW8KTTKMe5Az+RvlkDjMMs8S06kakt+q5RvwXcnXxQI=; b=aWyEOPj5eBO6YtiDRcoW+SdJ5AstZNlydj6vZs8OmxcHjq5w0rsc/txT9qgQzC6tmK UGPGCchluUxF9uEcyYofLAy1cQF8u7mQ/3G2o3TSIl7BvFda+oiW4lzV/5IcJw6OBx9A iu6tqx3rmgV6AWWgf6IFF54Id8rd239bXodyNzNGQIqc0T+84DyxaApq8uKwwqbNRlfl xaCWQtmR9TJahrnsCe8kqpnNhmu2uSyyXHr2KkZAe09jSBkOz5wkWwLoyJd4uDKAl1QM pUSmWgz+V8fKdwndE0fS+7tJ674e2yi9XrfyW05J6UUY2ft2ZMua5+6HBfwAklGfvWq1 BrRQ== X-Received: by 10.68.99.194 with SMTP id es2mr22310974pbb.100.1393886833952; Mon, 03 Mar 2014 14:47:13 -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 yo9sm91682306pab.16.2014.03.03.14.47.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 14:47:12 -0800 (PST) Received: by mcgrof@gmail.com (sSMTP sendmail emulation); Mon, 03 Mar 2014 14:47:08 -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 Subject: [RFC v3 0/6] networking: address root block upon initialization Date: Mon, 3 Mar 2014 14:46:59 -0800 Message-Id: <1393886825-24323-1-git-send-email-mcgrof@do-not-panic.com> X-Mailer: git-send-email 1.8.5.3 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: "Luis R. Rodriguez" This is my third series on addressing removing the xen-netback hack of using a high MAC address for a root block preference after feedback and testing of the bridge feature Stephen mentioned. We want to remove that hack as its possible to end up with IPv6 conflicts upon SLAAC and DAD. As per Stephen we want to use the root_block preference but this is a networking bridge port primitive, not a net_device feature. Since ndo_add_slave() only lets us pass a net_device *and* since the bridge code assumes outright that a slave devices can become a root port we have to use a private flag on the net_device if a driver wants to enable root block since initialization. If we don't address this preference early the device may end up as the designated port and can run into undesired link topology preferences. As I tested using the root block preference I noticed that if a net_device slave under the bridge gets the designated root port prior to setting in userspace the root_block feature enabling the feature won't kick the bridge to remove that net_device from the designated port. I addressed that issue and also upkeeping the initial random MAC address given to the bridge as if othwerwise we'd end up with a zero MAC address bridge if we root block all ports. I have only done local tests I'd appreciate a bit more wide test coverage and review. I suspect the TAP devices used for virtualization can also benefit from this flag so likewise since TAP devices can be tuned in userspace by design we must enable an option to pass to userspace to let the tun driver set the root block private flag prior to device registration. I'd be interested to hear if folks usng kvm in a bridged topology have run into this issue and if this addresses that issue there as well, I think it will. If someone wants to test this in qemu the patch below can be used, but note that this simply force-enables root block if the kernel has that feature. Since I've heard claims that some topologies exist where the virtualized backend device could be used as the designated port on the bridge it may be desirable to enable qemu users to specify their preference. If we however prove that we don't need this at all ever for backends we likley want this enabled always. These patches apply onto today's net-next. Luis R. Rodriguez (6): bridge: preserve random init MAC address bridge: trigger a bridge calculation upon port changes bridge: fix bridge root block on designated port bridge: enable root block during device registration xen-netback: use a random MAC address and force bridge root block tun: add initialization root block support drivers/net/tun.c | 6 ++- drivers/net/xen-netback/interface.c | 14 +++---- include/linux/netdevice.h | 7 ++++ include/uapi/linux/if_tun.h | 1 + net/bridge/br_device.c | 1 + net/bridge/br_if.c | 2 + net/bridge/br_netlink.c | 24 ++++++++++++ net/bridge/br_private.h | 2 + net/bridge/br_stp.c | 73 ++++++++++++++++++++++++++++++++++--- net/bridge/br_stp_if.c | 6 ++- 10 files changed, 119 insertions(+), 17 deletions(-) diff --git a/net/tap-linux.c b/net/tap-linux.c index 812bf2d..34be39d 100644 --- a/net/tap-linux.c +++ b/net/tap-linux.c @@ -61,6 +61,10 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr, ifr.ifr_flags |= IFF_ONE_QUEUE; } + if (features & IFF_ROOT_BLOCK) { + ifr.ifr_flags |= IFF_ROOT_BLOCK; + } + if (*vnet_hdr) { if (features & IFF_VNET_HDR) { *vnet_hdr = 1; diff --git a/net/tap-linux.h b/net/tap-linux.h index 1cf35d4..d59e477 100644 --- a/net/tap-linux.h +++ b/net/tap-linux.h @@ -42,6 +42,8 @@ #define IFF_ATTACH_QUEUE 0x0200 #define IFF_DETACH_QUEUE 0x0400 +#define IFF_ROOT_BLOCK 0x2000 + /* Features for GSO (TUNSETOFFLOAD). */ #define TUN_F_CSUM 0x01 /* You can hand me unchecksummed packets. */ #define TUN_F_TSO4 0x02 /* I can handle TSO for IPv4 packets */