* Re: [PATCH 2/2] drivers/net/phy/mdio-bitbang.c: Call mdiobus_unregister before mdiobus_free
From: David Miller @ 2012-11-03 1:36 UTC (permalink / raw)
To: peter.senna; +Cc: srinivas.kandagatla, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1351440721-9121-2-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Sun, 28 Oct 2012 17:12:01 +0100
> Based on commit b27393aecf66199f5ddad37c302d3e0cfadbe6c0
>
> Calling mdiobus_free without calling mdiobus_unregister causes
> BUG_ON(). This patch fixes the issue.
>
> The semantic patch that found this issue(http://coccinelle.lip6.fr/):
> // <smpl>
> @@
> expression E;
> @@
> ... when != mdiobus_unregister(E);
>
> + mdiobus_unregister(E);
> mdiobus_free(E);
> // </smpl>
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] drivers/net/ethernet/nxp/lpc_eth.c: Call mdiobus_unregister before mdiobus_free
From: David Miller @ 2012-11-03 1:36 UTC (permalink / raw)
To: peter.senna
Cc: stigge, edumazet, djduanjiong, aletes.xgr, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <1351440721-9121-1-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Sun, 28 Oct 2012 17:12:00 +0100
> Based on commit b27393aecf66199f5ddad37c302d3e0cfadbe6c0
>
> Calling mdiobus_free without calling mdiobus_unregister causes
> BUG_ON(). This patch fixes the issue.
>
> The semantic patch that found this issue(http://coccinelle.lip6.fr/):
> // <smpl>
> @@
> expression E;
> @@
> ... when != mdiobus_unregister(E);
>
> + mdiobus_unregister(E);
> mdiobus_free(E);
> // </smpl>
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/3] eth: Rename and properly align br_reserved_address array
From: David Miller @ 2012-11-03 1:34 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers, john.r.fastabend, shemminger
In-Reply-To: <1351797122.2883.14.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 1 Nov 2012 19:12:02 +0000
> Since this array is no longer part of the bridge driver, it should
> have an 'eth' prefix not 'br'.
>
> We also assume that either it's 16-bit-aligned or the architecture has
> efficient unaligned access. Ensure the first of these is true by
> explicitly aligning it.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] eth: Make is_link_local() consistent with other address tests
From: David Miller @ 2012-11-03 1:34 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, john.r.fastabend, shemminger
In-Reply-To: <1351797071.2883.13.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 1 Nov 2012 19:11:11 +0000
> Function name should include '_ether_addr'.
> Return type should be bool.
> Parameter name should be 'addr' not 'dest' (also matching kernel-doc).
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/3] bridge: Use is_link_local() in store_group_addr()
From: David Miller @ 2012-11-03 1:34 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, shemminger
In-Reply-To: <1351797004.2883.12.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 1 Nov 2012 19:10:04 +0000
> Parse the string into an array of bytes rather than ints, so we can
> use is_link_local() rather than reimplementing it.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] bnx2x: fix HW initialization using fw 7.8.x
From: David Miller @ 2012-11-03 1:32 UTC (permalink / raw)
To: dmitry; +Cc: netdev, ariele
In-Reply-To: <1351497544-13272-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Mon, 29 Oct 2012 09:59:04 +0200
> Since commit 96bed4b9 (use FW 7.8.2) BRB HW block needs to be
> initialized using fw values for all devices.
> Otherwise ETS on 57712/578xx will not work.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sfc: Select PTP_1588_CLOCK
From: David Miller @ 2012-11-03 1:31 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1351804942.2883.47.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 1 Nov 2012 21:22:22 +0000
> This was missed in commit a24006ed12616bde1bbdb26868495906a212d8dc
> ('ptp: Enable clock drivers along with associated net/PHY drivers')
> which enabled sfc's clock driver unconditionally.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks Ben.
^ permalink raw reply
* Re: [PATCHv3 net-next 0/8] enable/disable zero copy tx dynamically
From: David Miller @ 2012-11-03 1:31 UTC (permalink / raw)
To: mst
Cc: vyasevic, alexander.h.duyck, Ian.Campbell, kvm, netdev,
linux-kernel, virtualization, edumazet, akpm
In-Reply-To: <cover.1351797353.git.mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 1 Nov 2012 21:16:17 +0200
>
> tun supports zero copy transmit since 0690899b4d4501b3505be069b9a687e68ccbe15b,
> however you can only enable this mode if you know your workload does not
> trigger heavy guest to host/host to guest traffic - otherwise you
> get a (minor) performance regression.
> This patchset addresses this problem by notifying the owner
> device when callback is invoked because of a data copy.
> This makes it possible to detect whether zero copy is appropriate
> dynamically: we start in zero copy mode, when we detect
> data copied we disable zero copy for a while.
>
> With this patch applied, I get the same performance for
> guest to host and guest to guest both with and without zero copy tx.
Series applied, thanks Michael.
^ permalink raw reply
* Re: [PATCH V5 04/22] qlcnic: modify PCI and register access routines
From: David Miller @ 2012-11-03 1:27 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1351818414-25197-5-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Thu, 1 Nov 2012 21:06:36 -0400
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> Refactor 82xx driver to support new adapter - Qlogic 83XX CNA
> Update PCI and hardware access routines
>
> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
This removes the only user of qlcnic_check_vf() but leaves the
definition around, dangling, and creating a build warning:
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c:454:1: warning: ‘qlcnic_check_vf’ defined but not used [-Wunused-function]
Before you even bother sending this series yet another time, I want
you to do what I'm going to do with your patches anyways, which is
apply them one by one and verify that at each and every patch there
are no build failures or new warnings introduced.
My patience with you guys is wearing thin, and after being without
power or heat for 5 days I'm really grumpy. So you better take
your time and make sure this thing is perfect before you even
think about posting it again.
Thanks.
^ permalink raw reply
* Re: [net-next PATCH v2 1/3] net: create generic bridge ops
From: John Fastabend @ 2012-11-02 23:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: shemminger, buytenh, davem, vyasevic, jhs, chrisw, krkumar2,
samudrala, peter.p.waskiewicz.jr, jeffrey.t.kirsher, netdev,
gregory.v.rose, eilong
In-Reply-To: <1351895575.2703.5.camel@bwh-desktop.uk.solarflarecom.com>
On 11/2/2012 3:32 PM, Ben Hutchings wrote:
> On Wed, 2012-10-24 at 11:12 -0700, John Fastabend wrote:
>> The PF_BRIDGE:RTM_{GET|SET}LINK nlmsg family and type are
>> currently embedded in the ./net/bridge module. This prohibits
>> them from being used by other bridging devices. One example
>> of this being hardware that has embedded bridging components.
>>
>> In order to use these nlmsg types more generically this patch
>> adds two net_device_ops hooks. One to set link bridge attributes
>> and another to dump the current bride attributes.
>>
>> ndo_bridge_setlink()
>> ndo_bridge_getlink()
> [...]
>
> Do you have any userland code for this?
Just sent this to netdev. Or you can pull it here,
git://github.com/jrfastab/net-next-iproute2-jf.git
I'll test your idx fix now.
^ permalink raw reply
* [RFC PATCH] iproute2: bridge: add veb/vepa toggle
From: John Fastabend @ 2012-11-02 23:23 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, netdev
Add bridge commands to set veb, vepa modes to iproute2.
[root@jf-dev1-dcblab iproute2]# ./bridge/bridge bridge show
eth2: mode VEB bridge_flags: self
eth3: mode VEPA bridge_flags: self
eth10: mode VEB bridge_flags: self
eth12: mode VEB bridge_flags: self
[root@jf-dev1-dcblab iproute2]# ./bridge/bridge bridge er mode veb dev eth3 self
bridge_mode_set eth3: type 19 family 7 mode VEB flags 0002
[root@jf-dev1-dcblab iproute2]# ./bridge/bridge bridge show
eth2: mode VEB bridge_flags: self
eth3: mode VEB bridge_flags: self
eth10: mode VEB bridge_flags: self
eth12: mode VEB bridge_flags: self
Should add code to print the flags on error so the user can learn
what failed. And maybe the cmd line syntax could be better.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
bridge/br_common.h | 1
bridge/bridge.c | 3
bridge/fdb.c | 320 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/if_link.h | 16 ++
4 files changed, 339 insertions(+), 1 deletions(-)
diff --git a/bridge/br_common.h b/bridge/br_common.h
index 718ecb9..3e5dcab 100644
--- a/bridge/br_common.h
+++ b/bridge/br_common.h
@@ -5,6 +5,7 @@ extern int print_fdb(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg);
extern int do_fdb(int argc, char **argv);
+extern int do_bridge(int argc, char **argv);
extern int do_monitor(int argc, char **argv);
extern int preferred_family;
diff --git a/bridge/bridge.c b/bridge/bridge.c
index e2c33b0..b5145c1 100644
--- a/bridge/bridge.c
+++ b/bridge/bridge.c
@@ -27,7 +27,7 @@ static void usage(void)
{
fprintf(stderr,
"Usage: bridge [ OPTIONS ] OBJECT { COMMAND | help }\n"
-"where OBJECT := { fdb | monitor }\n"
+"where OBJECT := { fdb | monitor | bridge }\n"
" OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails]\n" );
exit(-1);
}
@@ -43,6 +43,7 @@ static const struct cmd {
int (*func)(int argc, char **argv);
} cmds[] = {
{ "fdb", do_fdb },
+ { "bridge", do_bridge },
{ "monitor", do_monitor },
{ "help", do_help },
{ 0 }
diff --git a/bridge/fdb.c b/bridge/fdb.c
index 4ca4861..1017307 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -34,6 +34,13 @@ static void usage(void)
exit(-1);
}
+static void bridge_usage(void)
+{
+ fprintf(stderr, "Usage: br bridge er mode {veb | vepa} dev DEV\n");
+ fprintf(stderr, " br bridge {show} [ dev DEV] \n");
+ exit(-1);
+}
+
static const char *state_n2a(unsigned s)
{
static char buf[32];
@@ -269,3 +276,316 @@ int do_fdb(int argc, char **argv)
fprintf(stderr, "Command \"%s\" is unknown, try \"bridge fdb help\".\n", *argv);
exit(-1);
}
+
+int print_bridge(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
+{
+ FILE *fp = arg;
+ struct ifinfomsg *ifm = NLMSG_DATA(n);
+ int len = n->nlmsg_len;
+ struct rtattr * tb[IFLA_MAX+1];
+
+ len -= NLMSG_LENGTH(sizeof(*ifm));
+ if (len < 0) {
+ fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
+ return -1;
+ }
+
+ if (ifm->ifi_family != AF_BRIDGE) {
+ fprintf(stderr, "hmm: Not PF_BRIDGE is %i\n", ifm->ifi_family);
+ }
+
+ if (filter_index && filter_index != ifm->ifi_index)
+ return 0;
+
+ parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifm), len);
+
+ if (!tb[IFLA_IFNAME]) {
+ fprintf(stderr, "%s: missing ifname using ifi_index %u name %s\n",
+ __func__, ifm->ifi_index,
+ ll_index_to_name(ifm->ifi_index));
+ }
+ if (tb[IFLA_AF_SPEC]) {
+ struct rtattr *bridge[IFLA_BRIDGE_MAX+1];
+ __u16 mode = 0, flags = 0;
+
+ parse_rtattr_nested(bridge, IFLA_BRIDGE_MAX, tb[IFLA_AF_SPEC]);
+ if (bridge[IFLA_BRIDGE_MODE])
+ mode =*(__u16*)RTA_DATA(bridge[IFLA_BRIDGE_MODE]);
+ if (bridge[IFLA_BRIDGE_FLAGS])
+ flags =*(__u16*)RTA_DATA(bridge[IFLA_BRIDGE_FLAGS]);
+
+ fprintf(stderr, "%s: mode %s bridge_flags: %s %s\n",
+ ll_index_to_name(ifm->ifi_index),
+ mode ? "VEPA" : "VEB",
+ flags & BRIDGE_FLAGS_SELF ? "self" : "",
+ flags & BRIDGE_FLAGS_MASTER ? "master" : "");
+ }
+
+ if (tb[IFLA_PROTINFO]) {
+ __u8 state = *(__u8*)RTA_DATA(tb[IFLA_PROTINFO]);
+ char *sstate;
+
+ switch (state) {
+ case 0:
+ sstate = "DISABLED";
+ break;
+ case 1:
+ sstate = "LISTENING";
+ break;
+ case 2:
+ sstate = "LEARNING";
+ break;
+ case 3:
+ sstate = "FORWARDING";
+ break;
+ case 4:
+ sstate = "BLOCKING";
+ break;
+ default:
+ sstate = "UNKNOWN";
+ break;
+ }
+
+
+ fprintf(stderr, "%s: ifla_protinfo: %s\n",
+ __func__, sstate);
+ }
+
+ fflush(fp);
+ return 0;
+}
+
+static int bridge_show(int argc, char **argv)
+{
+ char *filter_dev = NULL;
+
+
+ while (argc > 0) {
+ if (strcmp(*argv, "dev") == 0) {
+ NEXT_ARG();
+ if (filter_dev)
+ duparg("dev", *argv);
+
+ filter_dev = *argv;
+ }
+ argc--; argv++;
+ }
+
+ if (filter_dev) {
+ if ((filter_index = if_nametoindex(filter_dev)) == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n", filter_dev);
+ return -1;
+ }
+ }
+
+ if (rtnl_wilddump_request(&rth, PF_BRIDGE, RTM_GETLINK) < 0) {
+ perror("Cannot send dump request");
+ exit(1);
+ }
+
+ if (rtnl_dump_filter(&rth, print_bridge, stdout) < 0) {
+ fprintf(stderr, "Dump terminated\n");
+ exit(1);
+ }
+
+ return 0;
+}
+
+static int bridge_mode_set(int argc, char **argv)
+{
+ struct {
+ struct nlmsghdr n;
+ struct ifinfomsg ifm;
+ char buf[1024];
+ } req;
+ char *d = NULL;
+ __u16 mode = -1, flags = 0;
+ int err;
+ struct rtattr *binfo;
+
+ memset(&req, 0, sizeof(req));
+
+ req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
+ req.n.nlmsg_flags = NLM_F_REQUEST;
+ req.n.nlmsg_type = RTM_SETLINK;
+ req.ifm.ifi_family = PF_BRIDGE;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "dev") == 0) {
+ NEXT_ARG();
+ d = *argv;
+ } else if (matches(*argv, "mode") == 0) {
+ NEXT_ARG();
+ if (matches(*argv, "veb") == 0)
+ mode = BRIDGE_MODE_VEB;
+ else if (matches(*argv, "vepa") == 0)
+ mode = BRIDGE_MODE_VEPA;
+ else
+ invarg("Invalid mode value\n", *argv);
+
+ } else if (matches(*argv, "self") == 0 ) {
+ flags |= BRIDGE_FLAGS_SELF;
+ } else if (matches(*argv, "master") == 0 ) {
+ flags |= BRIDGE_FLAGS_MASTER;
+ }
+ argc--; argv++;
+ }
+
+ if (!d) {
+ fprintf(stderr, "Device required.\n");
+ exit(-1);
+ }
+
+ req.ifm.ifi_index = ll_name_to_index(d);
+ if (req.ifm.ifi_index == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n", d);
+ return -1;
+ }
+
+ binfo = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
+ err = addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
+ err = addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
+ if (err < 0)
+ fprintf(stderr, "addattr16 failes\n");
+ addattr_nest_end(&req.n, binfo);
+
+ printf("%s %s: type %i family %i mode %s flags %04x\n", __func__, d,
+ req.n.nlmsg_type, req.ifm.ifi_family,
+ mode ? "VEPA" : "VEB", flags);
+
+ if (rtnl_talk(&rth, &req.n, 0, 0, NULL) < 0)
+ exit(2);
+
+ return 0;
+}
+
+static int bridge_state_set(int argc, char **argv)
+{
+ struct {
+ struct nlmsghdr n;
+ struct ifinfomsg ifm;
+ char buf[1024];
+ } req;
+ struct {
+ struct nlmsghdr hdr;
+ struct nlmsgerr err;
+ struct nlmsghdr rhdr;
+ struct ifinfomsg ifm;
+ char buf[1024];
+ } reply;
+ char *d = NULL;
+ __u8 state = -1; //BRIDGE_MODE_VEB;
+ __u16 mode = 0, flags = 0; //BRIDGE_MODE_VEB;
+
+ memset(&req, 0, sizeof(req));
+ memset(&reply, 0, sizeof(reply));
+
+ req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
+ req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_REPLACE | NLM_F_ACK;
+ req.n.nlmsg_type = RTM_SETLINK;
+ req.ifm.ifi_family = PF_BRIDGE;
+
+ while (argc > 0) {
+ printf("%s: arg proc: %s\n", __func__, *argv);
+ if (strcmp(*argv, "dev") == 0) {
+ NEXT_ARG();
+ d = *argv;
+ } else if (matches(*argv, "state") == 0) {
+ NEXT_ARG();
+ printf("%s: arg matched state: %s\n", __func__, *argv);
+ if (matches(*argv, "DISABLED") == 0)
+ state = 0;
+ else if (matches(*argv, "LISTENING") == 0)
+ state = 1;
+ else if (matches(*argv, "LEARNING") == 0)
+ state = 2;
+ else if (matches(*argv, "FORWARDING") == 0)
+ state = 3;
+ else if (matches(*argv, "BLOCKING") == 0)
+ state = 4;
+ else
+ invarg("Invalid state value\n", *argv);
+
+ } else if (matches(*argv, "mode") == 0) {
+ NEXT_ARG();
+ printf("%s: arg set mode %s\n", __func__, *argv);
+ if (matches(*argv, "veb") == 0)
+ mode = BRIDGE_MODE_VEB;
+ else if (matches(*argv, "vepa") == 0)
+ mode = BRIDGE_MODE_VEPA;
+ else
+ invarg("Invalid mode value\n", *argv);
+
+ } else if (matches(*argv, "master") == 0) {
+ printf("%s: arg set master\n", __func__);
+ flags |= BRIDGE_FLAGS_MASTER;
+ } else if (matches(*argv, "self") == 0) {
+ printf("%s: arg set self\n", __func__);
+ flags |= BRIDGE_FLAGS_SELF;
+ }
+
+ argc--; argv++;
+ }
+
+ if (!d) {
+ fprintf(stderr, "Device required.\n");
+ exit(-1);
+ }
+
+ req.ifm.ifi_index = ll_name_to_index(d);
+ if (req.ifm.ifi_index == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n", d);
+ return -1;
+ }
+
+ if (state < 4)
+ addattr8(&req.n, sizeof(req.buf), IFLA_PROTINFO, state);
+
+ printf("%s %s(%u): type %i family %i state 0x%2x\n", __func__, d, req.ifm.ifi_index,
+ req.n.nlmsg_type, req.ifm.ifi_family, state);
+
+ if (mode < 3 || flags) {
+ struct rtattr *binfo;
+ int err = 0;
+
+ binfo = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
+ if (flags)
+ err = addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
+ if (mode < 3)
+ err = addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
+ if (err < 0)
+ fprintf(stderr, "addattr16 failes\n");
+ addattr_nest_end(&req.n, binfo);
+
+ printf("%s %s(%u): type %i family %i mode %s\n", __func__, d, req.ifm.ifi_index,
+ req.n.nlmsg_type, req.ifm.ifi_family,
+ mode ? "VEPA" : "VEB");
+ }
+
+ printf("%s: %s(%u): rtnl_talk length %u\n", __func__, d, req.ifm.ifi_index, req.n.nlmsg_len);
+ if (rtnl_talk(&rth, &req.n, 0, 0, &reply.hdr) < 0) {
+ printf("\nREPLY: error %i\n", reply.err.error);
+ print_bridge(NULL, &reply.err.msg, stderr);
+ exit(2);
+ }
+
+ return 0;
+}
+
+int do_bridge(int argc, char **argv)
+{
+ ll_init_map(&rth);
+
+ if (argc > 0) {
+ if (matches(*argv, "er") == 0)
+ return bridge_mode_set(argc-1, argv+1);
+ else if (matches(*argv, "show") == 0)
+ return bridge_show(argc-1, argv+1);
+ else if (matches(*argv, "state") == 0)
+ return bridge_state_set(argc-1, argv+1);
+ else if (matches(*argv, "help") == 0)
+ bridge_usage();
+ }
+
+ exit(0);
+}
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 012d95a..1a6c2f1 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -142,6 +142,7 @@ enum {
#define IFLA_PROMISCUITY IFLA_PROMISCUITY
IFLA_NUM_TX_QUEUES,
IFLA_NUM_RX_QUEUES,
+ IFLA_BRIDGE,
__IFLA_MAX
};
@@ -375,6 +376,21 @@ enum {
#define PORT_UUID_MAX 16
#define PORT_SELF_VF -1
+/* Bridge Flags */
+#define BRIDGE_FLAGS_MASTER 1 /* Bridge command to/from master */
+#define BRIDGE_FLAGS_SELF 2 /* Bridge command to/from lowerdev */
+
+#define BRIDGE_MODE_VEB 0 /* Default loopback mode */
+#define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
+
+/* Bridge management nested attributes */
+enum {
+ IFLA_BRIDGE_FLAGS,
+ IFLA_BRIDGE_MODE,
+ __IFLA_BRIDGE_MAX,
+};
+#define IFLA_BRIDGE_MAX (__IFLA_BRIDGE_MAX - 1)
+
enum {
PORT_REQUEST_PREASSOCIATE = 0,
PORT_REQUEST_PREASSOCIATE_RR,
^ permalink raw reply related
* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Ben Hutchings @ 2012-11-02 23:34 UTC (permalink / raw)
To: Brian Haley
Cc: Pavel Emelyanov, David Miller, Eric Dumazet,
netdev@vger.kernel.org
In-Reply-To: <5093E09A.6000004@hp.com>
On Fri, 2012-11-02 at 11:02 -0400, Brian Haley wrote:
> On 11/02/2012 05:36 AM, Pavel Emelyanov wrote:
> >> +static int sock_getbindtodevice(struct sock *sk, char __user *optval,
> >> + int __user *optlen, int len)
> >> +{
> >> + int ret = -ENOPROTOOPT;
> >> +#ifdef CONFIG_NETDEVICES
> >> + struct net *net = sock_net(sk);
> >> + struct net_device *dev;
> >> + char devname[IFNAMSIZ];
> >> +
> >> + if (sk->sk_bound_dev_if == 0) {
> >> + len = 0;
> >> + goto zero;
> >> + }
> >> +
> >> + ret = -EINVAL;
> >> + if (len < IFNAMSIZ)
> >> + goto out;
> >> +
> >> + rcu_read_lock();
> >> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
> >> + if (dev)
> >> + strcpy(devname, dev->name);
> >
> > This still races with the device name change, potentially providing
> > a name which never existed in the system, doesn't it?
>
> My only argument here is that SIOCGIFNAME has had this same code forever, and
> noone has ever complained about that returning a garbled name. Even
> dev_get_by_name() only holds an rcu lock when doing a strncmp().
>
> We'd need to audit the whole kernel to catch all the places where we potentially
> look at dev->name while it could change. Is it really worth it?
A net device name can't be changed while the device is up, or while
another task holds the RTNL lock. I think that covers almost all uses.
I don't know whether it's worth going out to look for exceptions, but we
might as well fix the cases we know about.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 0/4] Support the MX6 FEC as a PTP hardware clock
From: Ben Hutchings @ 2012-11-02 23:25 UTC (permalink / raw)
To: Richard Cochran, Frank Li
Cc: David Miller, Frank.Li, shawn.guo, linux-arm-kernel, netdev
In-Reply-To: <20121102084324.GA2486@netboy.at.omicron.at>
On Fri, 2012-11-02 at 09:43 +0100, Richard Cochran wrote:
> On Fri, Nov 02, 2012 at 10:36:09AM +0800, Frank Li wrote:
> > >
> > > All applied to net-next.
> > >
> > > Please make sure your changes are in sync with Ben's PTP/PPS
> > > Kconfig changes of today, and send me any changes if necessary.
> > >
> >
> > Thank you very much.
> > I checked Ben's patch, which not affect FEC.
>
> Maybe just remove the Kconfig line "select PPS".
More than that: FEC should select PTP_1588_CLOCK, FEC_PTP should be
removed and all the conditional code made unconditional. Alternately,
if that would cost too much (in terms of performance or memory) on some
systems where the driver is used, FEC_PTP should default to 'y'.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next] net: Fix continued iteration in rtnl_bridge_getlink()
From: Ben Hutchings @ 2012-11-02 23:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, John Fastabend, Stephen Hemminger
In-Reply-To: <1351897012.2703.17.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, 2012-11-02 at 22:56 +0000, Ben Hutchings wrote:
[...]
> I'm still not sure it's correct to break iteration if
> ndo_bridge_getlink returns -EOPNOTSUPP (possible if the driver supports
> a mixture of bridging and non-bridging devices).
[...]
Never mind that - the driver can just return 0 for those devices, as
ixgbe is doing. But the bug this patch addresses seems to be real.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next PATCH v2 2/3] net: set and query VEB/VEPA bridge mode via PF_BRIDGE
From: John Fastabend @ 2012-11-02 23:03 UTC (permalink / raw)
To: Ben Hutchings
Cc: shemminger, buytenh, davem, vyasevic, jhs, chrisw, krkumar2,
samudrala, peter.p.waskiewicz.jr, jeffrey.t.kirsher, netdev,
gregory.v.rose, eilong
In-Reply-To: <1351897261.2703.21.camel@bwh-desktop.uk.solarflarecom.com>
On 11/2/2012 4:01 PM, Ben Hutchings wrote:
> On Fri, 2012-11-02 at 15:48 -0700, John Fastabend wrote:
>> On 11/2/2012 3:38 PM, Ben Hutchings wrote:
>>> On Wed, 2012-10-24 at 11:13 -0700, John Fastabend wrote:
>>>> Hardware switches may support enabling and disabling the
>>>> loopback switch which puts the device in a VEPA mode defined
>>>> in the IEEE 802.1Qbg specification. In this mode frames are
>>>> not switched in the hardware but sent directly to the switch.
>>>> SR-IOV capable NICs will likely support this mode I am
>>>> aware of at least two such devices. Also I am told (but don't
>>>> have any of this hardware available) that there are devices
>>>> that only support VEPA modes. In these cases it is important
>>>> at a minimum to be able to query these attributes.
>>>>
>>>> This patch adds an additional IFLA_BRIDGE_MODE attribute that can be
>>>> set and dumped via the PF_BRIDGE:{SET|GET}LINK operations. Also
>>>> anticipating bridge attributes that may be common for both embedded
>>>> bridges and software bridges this adds a flags attribute
>>>> IFLA_BRIDGE_FLAGS currently used to determine if the command or event
>>>> is being generated to/from an embedded bridge or software bridge.
>>>> Finally, the event generation is pulled out of the bridge module and
>>>> into rtnetlink proper.
> [...]
>>>> + if (attr && nla_type(attr) == IFLA_BRIDGE_FLAGS)
>>>
>>> This condition is wrong; attr will *not* be NULL if the
>>> nla_for_each_nested() loop terminates without finding an
>>> IFLA_BRIDGE_FLAGS attribute.
>>
>> It might be NULL if the nlmsg has no IFLA_AF_SPEC attr. In this case
>> we still need to send the PROTINFO attribute to the master which
>> could be the linux bridge.
> [...]
>
> I think nla_for_each_nested() can leave attr non-null but also not valid
> for use with nla_type(). And that's a problem. I think it would be
> better to use an explicit flag for whether we found that attribute,
> rather than trying to re-test here.
>
> Ben.
>
OK. I'll add an explicit flag for this. Thanks.
^ permalink raw reply
* Re: [net-next PATCH v2 2/3] net: set and query VEB/VEPA bridge mode via PF_BRIDGE
From: Ben Hutchings @ 2012-11-02 23:01 UTC (permalink / raw)
To: John Fastabend
Cc: shemminger, buytenh, davem, vyasevic, jhs, chrisw, krkumar2,
samudrala, peter.p.waskiewicz.jr, jeffrey.t.kirsher, netdev,
gregory.v.rose, eilong
In-Reply-To: <50944DC0.5060209@intel.com>
On Fri, 2012-11-02 at 15:48 -0700, John Fastabend wrote:
> On 11/2/2012 3:38 PM, Ben Hutchings wrote:
> > On Wed, 2012-10-24 at 11:13 -0700, John Fastabend wrote:
> >> Hardware switches may support enabling and disabling the
> >> loopback switch which puts the device in a VEPA mode defined
> >> in the IEEE 802.1Qbg specification. In this mode frames are
> >> not switched in the hardware but sent directly to the switch.
> >> SR-IOV capable NICs will likely support this mode I am
> >> aware of at least two such devices. Also I am told (but don't
> >> have any of this hardware available) that there are devices
> >> that only support VEPA modes. In these cases it is important
> >> at a minimum to be able to query these attributes.
> >>
> >> This patch adds an additional IFLA_BRIDGE_MODE attribute that can be
> >> set and dumped via the PF_BRIDGE:{SET|GET}LINK operations. Also
> >> anticipating bridge attributes that may be common for both embedded
> >> bridges and software bridges this adds a flags attribute
> >> IFLA_BRIDGE_FLAGS currently used to determine if the command or event
> >> is being generated to/from an embedded bridge or software bridge.
> >> Finally, the event generation is pulled out of the bridge module and
> >> into rtnetlink proper.
[...]
> >> + if (attr && nla_type(attr) == IFLA_BRIDGE_FLAGS)
> >
> > This condition is wrong; attr will *not* be NULL if the
> > nla_for_each_nested() loop terminates without finding an
> > IFLA_BRIDGE_FLAGS attribute.
>
> It might be NULL if the nlmsg has no IFLA_AF_SPEC attr. In this case
> we still need to send the PROTINFO attribute to the master which
> could be the linux bridge.
[...]
I think nla_for_each_nested() can leave attr non-null but also not valid
for use with nla_type(). And that's a problem. I think it would be
better to use an explicit flag for whether we found that attribute,
rather than trying to re-test here.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next] net: Fix continued iteration in rtnl_bridge_getlink()
From: Ben Hutchings @ 2012-11-02 22:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, John Fastabend, Stephen Hemminger
Commit e5a55a898720096f43bc24938f8875c0a1b34cd7 ('net: create generic
bridge ops') broke the handling of a non-zero starting index in
rtnl_bridge_getlink() (based on the old br_dump_ifinfo()).
When the starting index is non-zero, we need to increment the current
index for each entry that we are skipping. Also, we need to check the
index before both cases, since we may previously have stopped
iteration between getting information about a device from its master
and from itself.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This is compile-tested only, as I don't know what userland code to test
with. I'm still not sure it's correct to break iteration if
ndo_bridge_getlink returns -EOPNOTSUPP (possible if the driver supports
a mixture of bridging and non-bridging devices).
Ben.
net/core/rtnetlink.c | 23 +++++++----------------
1 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 51dc58f..a0e35076 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2315,28 +2315,19 @@ static int rtnl_bridge_getlink(struct sk_buff *skb, struct netlink_callback *cb)
const struct net_device_ops *ops = dev->netdev_ops;
struct net_device *master = dev->master;
- if (idx < cb->args[0])
- continue;
-
if (master && master->netdev_ops->ndo_bridge_getlink) {
- const struct net_device_ops *bops = master->netdev_ops;
- int err = bops->ndo_bridge_getlink(skb, portid,
- seq, dev);
-
- if (err < 0)
+ if (idx >= cb->args[0] &&
+ master->netdev_ops->ndo_bridge_getlink(
+ skb, portid, seq, dev) < 0)
break;
- else
- idx++;
+ idx++;
}
if (ops->ndo_bridge_getlink) {
- int err = ops->ndo_bridge_getlink(skb, portid,
- seq, dev);
-
- if (err < 0)
+ if (idx >= cb->args[0] &&
+ ops->ndo_bridge_getlink(skb, portid, seq, dev) < 0)
break;
- else
- idx++;
+ idx++;
}
}
rcu_read_unlock();
--
1.7.7.6
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [net-next PATCH v2 2/3] net: set and query VEB/VEPA bridge mode via PF_BRIDGE
From: John Fastabend @ 2012-11-02 22:48 UTC (permalink / raw)
To: Ben Hutchings
Cc: shemminger, buytenh, davem, vyasevic, jhs, chrisw, krkumar2,
samudrala, peter.p.waskiewicz.jr, jeffrey.t.kirsher, netdev,
gregory.v.rose, eilong
In-Reply-To: <1351895923.2703.11.camel@bwh-desktop.uk.solarflarecom.com>
On 11/2/2012 3:38 PM, Ben Hutchings wrote:
> On Wed, 2012-10-24 at 11:13 -0700, John Fastabend wrote:
>> Hardware switches may support enabling and disabling the
>> loopback switch which puts the device in a VEPA mode defined
>> in the IEEE 802.1Qbg specification. In this mode frames are
>> not switched in the hardware but sent directly to the switch.
>> SR-IOV capable NICs will likely support this mode I am
>> aware of at least two such devices. Also I am told (but don't
>> have any of this hardware available) that there are devices
>> that only support VEPA modes. In these cases it is important
>> at a minimum to be able to query these attributes.
>>
>> This patch adds an additional IFLA_BRIDGE_MODE attribute that can be
>> set and dumped via the PF_BRIDGE:{SET|GET}LINK operations. Also
>> anticipating bridge attributes that may be common for both embedded
>> bridges and software bridges this adds a flags attribute
>> IFLA_BRIDGE_FLAGS currently used to determine if the command or event
>> is being generated to/from an embedded bridge or software bridge.
>> Finally, the event generation is pulled out of the bridge module and
>> into rtnetlink proper.
> [...]
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
> [...]
>> +static int rtnl_bridge_notify(struct net_device *dev, u16 flags)
>> +{
>> + struct net *net = dev_net(dev);
>> + struct net_device *master = dev->master;
>> + struct sk_buff *skb;
>> + int err = -EOPNOTSUPP;
>> +
>> + skb = nlmsg_new(bridge_nlmsg_size(), GFP_ATOMIC);
>> + if (!skb) {
>> + err = -ENOMEM;
>> + goto errout;
>> + }
>> +
>> + if (!flags && master && master->netdev_ops->ndo_bridge_getlink)
>> + err = master->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev);
>> + else if (dev->netdev_ops->ndo_bridge_getlink)
>> + err = dev->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev);
>
> This doesn't make sense. If flags == BRIDGE_FLAGS_MASTER then we only
> send the 'self' information. If flags == BRIDGE_FLAGS_MASTER |
> BRIDGE_FLAGS_SELF then we only send the master information.
>
agh. I screwed this up when I made this handle setting both master
and self flags. I'll fix it. Thanks.
> [...]
>> static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh,
>> void *arg)
>> {
>> struct net *net = sock_net(skb->sk);
>> struct ifinfomsg *ifm;
>> struct net_device *dev;
>> - int err = -EINVAL;
>> + struct nlattr *br_spec, *attr = NULL;
>> + int rem, err = -EOPNOTSUPP;
>> + u16 flags = 0;
>>
>> if (nlmsg_len(nlh) < sizeof(*ifm))
>> return -EINVAL;
>> @@ -2316,15 +2363,45 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh,
>> return -ENODEV;
>> }
>>
>> - if (dev->master && dev->master->netdev_ops->ndo_bridge_setlink) {
>> + br_spec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
>> + if (br_spec) {
>> + nla_for_each_nested(attr, br_spec, rem) {
>> + if (nla_type(attr) == IFLA_BRIDGE_FLAGS) {
>> + flags = nla_get_u16(attr);
>> + break;
>> + }
>> + }
>> + }
>> +
>> + if (!flags || (flags & BRIDGE_FLAGS_MASTER)) {
>> + if (!dev->master ||
>> + !dev->master->netdev_ops->ndo_bridge_setlink) {
>> + err = -EOPNOTSUPP;
>> + goto out;
>> + }
>> +
>> err = dev->master->netdev_ops->ndo_bridge_setlink(dev, nlh);
>> if (err)
>> goto out;
>> +
>> + flags &= ~BRIDGE_FLAGS_MASTER;
>> }
>>
>> - if (dev->netdev_ops->ndo_bridge_setlink)
>> - err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
>> + if ((flags & BRIDGE_FLAGS_SELF)) {
>> + if (!dev->netdev_ops->ndo_bridge_setlink)
>> + err = -EOPNOTSUPP;
>> + else
>> + err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
>> +
>> + if (!err)
>> + flags &= ~BRIDGE_FLAGS_SELF;
>> + }
>>
>> + if (attr && nla_type(attr) == IFLA_BRIDGE_FLAGS)
>
> This condition is wrong; attr will *not* be NULL if the
> nla_for_each_nested() loop terminates without finding an
> IFLA_BRIDGE_FLAGS attribute.
It might be NULL if the nlmsg has no IFLA_AF_SPEC attr. In this case
we still need to send the PROTINFO attribute to the master which
could be the linux bridge.
>
>> + memcpy(nla_data(attr), &flags, sizeof(flags));
>> + /* Generate event to notify upper layer of bridge change */
>> + if (!err)
>> + err = rtnl_bridge_notify(dev, flags);
>
> flags has been modified above; surely we want to use the original value
> here?
Yes. Thanks Ben. I'll have a patch shortly.
>
> Ben.
>
>> out:
>> return err;
>> }
>>
>
^ permalink raw reply
* Re: [net-next 0/6][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-11-02 22:46 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1351802715.2080.35.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 01 Nov 2012 13:45:15 -0700
> REALLY Sorry, I forgot to push the patches up to kernel.org. I have
> pushed them up now.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [net-next PATCH v2 2/3] net: set and query VEB/VEPA bridge mode via PF_BRIDGE
From: Ben Hutchings @ 2012-11-02 22:38 UTC (permalink / raw)
To: John Fastabend
Cc: shemminger, buytenh, davem, vyasevic, jhs, chrisw, krkumar2,
samudrala, peter.p.waskiewicz.jr, jeffrey.t.kirsher, netdev,
gregory.v.rose, eilong
In-Reply-To: <20121024181303.14378.78253.stgit@jf-dev1-dcblab>
On Wed, 2012-10-24 at 11:13 -0700, John Fastabend wrote:
> Hardware switches may support enabling and disabling the
> loopback switch which puts the device in a VEPA mode defined
> in the IEEE 802.1Qbg specification. In this mode frames are
> not switched in the hardware but sent directly to the switch.
> SR-IOV capable NICs will likely support this mode I am
> aware of at least two such devices. Also I am told (but don't
> have any of this hardware available) that there are devices
> that only support VEPA modes. In these cases it is important
> at a minimum to be able to query these attributes.
>
> This patch adds an additional IFLA_BRIDGE_MODE attribute that can be
> set and dumped via the PF_BRIDGE:{SET|GET}LINK operations. Also
> anticipating bridge attributes that may be common for both embedded
> bridges and software bridges this adds a flags attribute
> IFLA_BRIDGE_FLAGS currently used to determine if the command or event
> is being generated to/from an embedded bridge or software bridge.
> Finally, the event generation is pulled out of the bridge module and
> into rtnetlink proper.
[...]
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
[...]
> +static int rtnl_bridge_notify(struct net_device *dev, u16 flags)
> +{
> + struct net *net = dev_net(dev);
> + struct net_device *master = dev->master;
> + struct sk_buff *skb;
> + int err = -EOPNOTSUPP;
> +
> + skb = nlmsg_new(bridge_nlmsg_size(), GFP_ATOMIC);
> + if (!skb) {
> + err = -ENOMEM;
> + goto errout;
> + }
> +
> + if (!flags && master && master->netdev_ops->ndo_bridge_getlink)
> + err = master->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev);
> + else if (dev->netdev_ops->ndo_bridge_getlink)
> + err = dev->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev);
This doesn't make sense. If flags == BRIDGE_FLAGS_MASTER then we only
send the 'self' information. If flags == BRIDGE_FLAGS_MASTER |
BRIDGE_FLAGS_SELF then we only send the master information.
[...]
> static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh,
> void *arg)
> {
> struct net *net = sock_net(skb->sk);
> struct ifinfomsg *ifm;
> struct net_device *dev;
> - int err = -EINVAL;
> + struct nlattr *br_spec, *attr = NULL;
> + int rem, err = -EOPNOTSUPP;
> + u16 flags = 0;
>
> if (nlmsg_len(nlh) < sizeof(*ifm))
> return -EINVAL;
> @@ -2316,15 +2363,45 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh,
> return -ENODEV;
> }
>
> - if (dev->master && dev->master->netdev_ops->ndo_bridge_setlink) {
> + br_spec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
> + if (br_spec) {
> + nla_for_each_nested(attr, br_spec, rem) {
> + if (nla_type(attr) == IFLA_BRIDGE_FLAGS) {
> + flags = nla_get_u16(attr);
> + break;
> + }
> + }
> + }
> +
> + if (!flags || (flags & BRIDGE_FLAGS_MASTER)) {
> + if (!dev->master ||
> + !dev->master->netdev_ops->ndo_bridge_setlink) {
> + err = -EOPNOTSUPP;
> + goto out;
> + }
> +
> err = dev->master->netdev_ops->ndo_bridge_setlink(dev, nlh);
> if (err)
> goto out;
> +
> + flags &= ~BRIDGE_FLAGS_MASTER;
> }
>
> - if (dev->netdev_ops->ndo_bridge_setlink)
> - err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
> + if ((flags & BRIDGE_FLAGS_SELF)) {
> + if (!dev->netdev_ops->ndo_bridge_setlink)
> + err = -EOPNOTSUPP;
> + else
> + err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
> +
> + if (!err)
> + flags &= ~BRIDGE_FLAGS_SELF;
> + }
>
> + if (attr && nla_type(attr) == IFLA_BRIDGE_FLAGS)
This condition is wrong; attr will *not* be NULL if the
nla_for_each_nested() loop terminates without finding an
IFLA_BRIDGE_FLAGS attribute.
> + memcpy(nla_data(attr), &flags, sizeof(flags));
> + /* Generate event to notify upper layer of bridge change */
> + if (!err)
> + err = rtnl_bridge_notify(dev, flags);
flags has been modified above; surely we want to use the original value
here?
Ben.
> out:
> return err;
> }
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] Wireless: rt2x00: Add device id for Sweex LW323 to rt2800usb.c
From: Jaume Delclòs Coll @ 2012-11-02 22:35 UTC (permalink / raw)
To: IvDoorn, gwingerde, helmut.schaa, linville
Cc: linux-wireless, users, netdev, linux-kernel
From: Jaume Delclòs <jaume@delclos.com>
This patch adds detection for the Sweex LW323 USB wireless network card
in the rt2x00 driver (just one line in rt2800usb.c).
It applies to linux-3.7-rc3.
Signed-off-by: Jaume Delclòs <jaume@delclos.com>
--- linux-3.7-rc3/drivers/net/wireless/rt2x00/rt2800usb.c.orig 2012-11-02 21:14:01.393082623 +0100
+++ linux-3.7-rc3/drivers/net/wireless/rt2x00/rt2800usb.c 2012-11-02 21:14:57.502778651 +0100
@@ -1096,6 +1096,7 @@ static struct usb_device_id rt2800usb_de
{ USB_DEVICE(0x177f, 0x0153) },
{ USB_DEVICE(0x177f, 0x0302) },
{ USB_DEVICE(0x177f, 0x0313) },
+ { USB_DEVICE(0x177f, 0x0323) },
/* U-Media */
{ USB_DEVICE(0x157e, 0x300e) },
{ USB_DEVICE(0x157e, 0x3013) },
^ permalink raw reply
* Re: [net-next PATCH v2 1/3] net: create generic bridge ops
From: Ben Hutchings @ 2012-11-02 22:32 UTC (permalink / raw)
To: John Fastabend
Cc: shemminger, buytenh, davem, vyasevic, jhs, chrisw, krkumar2,
samudrala, peter.p.waskiewicz.jr, jeffrey.t.kirsher, netdev,
gregory.v.rose, eilong
In-Reply-To: <20121024181257.14378.41548.stgit@jf-dev1-dcblab>
On Wed, 2012-10-24 at 11:12 -0700, John Fastabend wrote:
> The PF_BRIDGE:RTM_{GET|SET}LINK nlmsg family and type are
> currently embedded in the ./net/bridge module. This prohibits
> them from being used by other bridging devices. One example
> of this being hardware that has embedded bridging components.
>
> In order to use these nlmsg types more generically this patch
> adds two net_device_ops hooks. One to set link bridge attributes
> and another to dump the current bride attributes.
>
> ndo_bridge_setlink()
> ndo_bridge_getlink()
[...]
Do you have any userland code for this?
[...]
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2252,6 +2252,83 @@ static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
> return skb->len;
> }
>
> +static int rtnl_bridge_getlink(struct sk_buff *skb, struct netlink_callback *cb)
> +{
> + struct net *net = sock_net(skb->sk);
> + struct net_device *dev;
> + int idx = 0;
> + u32 portid = NETLINK_CB(cb->skb).portid;
> + u32 seq = cb->nlh->nlmsg_seq;
> +
> + rcu_read_lock();
> + for_each_netdev_rcu(net, dev) {
> + const struct net_device_ops *ops = dev->netdev_ops;
> + struct net_device *master = dev->master;
> +
> + if (idx < cb->args[0])
> + continue;
[...]
This is wrong, as idx will not be incremented and continued iteration
won't work at all. Since this has already been applied, I'll send a
patch for this.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v4] Network driver for the Armada 370 and Armada XP ARM Marvell SoCs
From: Thomas Petazzoni @ 2012-11-02 22:21 UTC (permalink / raw)
To: Eric Dumazet, David S. Miller, Lennert Buytenhek, Francois Romieu
Cc: netdev, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Gregory Clement, Lior Amsalem, Maen Suleiman
In-Reply-To: <20121030105154.5b7c8e48@skate>
Hello,
On Tue, 30 Oct 2012 10:51:54 +0100, Thomas Petazzoni wrote:
> > This patch set adds a new network driver for the network unit
> > available in the newest Marvell ARM SoCs Armada 370 and Armada XP,
> > as well as the necessary Device Tree information to use this driver
> > in the two evaluation platforms of those SoCs.
>
> Besides Nobuhiro's small comment on the Device Tree part, are there
> any comments on the driver itself, or is the code good to go?
>
> I can send a fifth version with just the fix for Nobuhiro's comment,
> but it probably makes sense to take into account a few more comments
> (if any) at the same time.
Any comments on this patch set? What should I do to make it progress
towards integration?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Loan offer...Send Your Inquiry
From: Gulf International Bank @ 2012-11-02 21:15 UTC (permalink / raw)
Our bank offers personal and business loan at 2% interest rate. If
interested, contact us via (gulfib30@gmail.com) for further details.
MD, GIB.
^ permalink raw reply
* Re: switching network namespace midway
From: Eric W. Biederman @ 2012-11-02 20:45 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: rsa, netdev
In-Reply-To: <20121102140353.GE18091@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> writes:
> On Thu, Nov 01, 2012 at 11:18:58PM -0700, Eric W. Biederman wrote:
>> You need a per network namespace exit function to delete the tunnel when
>> the xmit direction goes away. Otherwise we have a very nasty race if
>> the original network namespace exits.
>
> That already exists as ipgre_exit_net(). Since the ip_tunnel structure
> remains hashed in the network namespace that creation occurred in, this
> case should be covered.
*blink* I had looked for that, but I definitely missed that one.
The consequence of the design where we can run ioctls on network devices
we can't even see but whose ipaddrs are in our network namespace is
interesting. Correct but interesting.
>> NETNS_LOCAL may make sense on the reference device that is used to
>> support ioctls for creating devices.
>
> *nod* That makes sense.
After a second look. fb_tunnel_dev is very special in the code so
allowing fb_tunnel_dev to change network namespace is almost certain
to create problems, so it should get a NETNS_LOCAL.
>> ipgre_open ? It looks like it needs to be handled. Probably that
>> ip_route_output_gre needs to be moved.
>
> Good catch. Will respin with that changed.
I'm not seeing anything else but I will look again after you respin.
>> ipv6?
>
> That's next on the list. There are also issues with ipip, ipmr and
> ipvti, as well as their ipv6 versions.
I don't see sense in ip multicast routing tunnels (ipmr) changing
network namespaces as they are essentially aliases for other network
devices, and aren't really proper tunnels.
Eric
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox