* Re: [Linux-decnet-user] Proposed removal of DECnet support (was:Re: [BUG] 3.2-rc2:BUG kmalloc-8: Redzone overwritten)
From: mike.gair @ 2011-11-30 13:52 UTC (permalink / raw)
To: Philipp Schafft
Cc: Chrissie Caulfield, Christoph Lameter, David Miller, Eric Dumazet,
Sasha Levin, Linux-DECnet user, linux-kernel, linux-mm,
Matt Mackall, netdev, Pekka Enberg, RoarAudio, Steven Whitehouse
In-Reply-To: <20111129144720.7374B7AD9E@priderock.keep-cool.org>
[-- Attachment #1: Type: text/html, Size: 5010 bytes --]
^ permalink raw reply
* Re: Integration of Open vSwitch
From: jamal @ 2011-11-30 14:01 UTC (permalink / raw)
To: Herbert Xu
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Chris Wright, Eric Dumazet, netdev,
John Fastabend, Stephen Hemminger, David Miller
In-Reply-To: <20111130134028.GA3226-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Wed, 2011-11-30 at 21:40 +0800, Herbert Xu wrote:
> I actually meant the scalability with adding/deleting flows,
> or in the case with qdiscs, filters.
Ah yes, them locks. Unless you start doing per-cpu tables
with lazy synchronization i am not sure how to avoid that.
Note: last time (time flies) i compared against iptables, the tc flow
setup/teardown was pretty consistent regardless of table size
relatively speaking.
cheers,
jamal
^ permalink raw reply
* RE: [Linux-decnet-user] Proposed removal of DECnet support
From: Bob Armstrong @ 2011-11-30 14:03 UTC (permalink / raw)
To: 'Philipp Schafft'
Cc: 'Christoph Lameter', 'Eric Dumazet',
'netdev', 'Linux-DECnet user',
'linux-kernel', 'Pekka Enberg',
'linux-mm', 'Chrissie Caulfield',
'Sasha Levin', 'Matt Mackall',
'RoarAudio', 'David Miller',
'Steven Whitehouse'
In-Reply-To: <20111129144720.7374B7AD9E@priderock.keep-cool.org>
> Philipp Schafft wrote:
>I'm very interested in the module.
Sorry to butt in - I got this message via Philipp and the
linux-decnet-user list - but I can also confirm that the linux DECnet
implementation does work against real DEC hardware and software. The guys
over in the HECnet group
http://www.update.uu.se/~bqt/hecnet.html
use it all the time. If you want access to real hardware and/or real
software to test it against, contact me and I can set something up.
Bob Armstrong
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] sch_teql: fix lockdep splat
From: Eric Dumazet @ 2011-11-30 14:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
We need rcu_read_lock() protection before using dst_get_neighbour(), and
we must cache its value (pass it to __teql_resolve())
teql_master_xmit() is called under rcu_read_lock_bh() protection, its
not enough.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_teql.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/net/sched/sch_teql.c b/net/sched/sch_teql.c
index a3b7120..4f4c52c 100644
--- a/net/sched/sch_teql.c
+++ b/net/sched/sch_teql.c
@@ -225,11 +225,11 @@ static int teql_qdisc_init(struct Qdisc *sch, struct nlattr *opt)
static int
-__teql_resolve(struct sk_buff *skb, struct sk_buff *skb_res, struct net_device *dev)
+__teql_resolve(struct sk_buff *skb, struct sk_buff *skb_res,
+ struct net_device *dev, struct netdev_queue *txq,
+ struct neighbour *mn)
{
- struct netdev_queue *dev_queue = netdev_get_tx_queue(dev, 0);
- struct teql_sched_data *q = qdisc_priv(dev_queue->qdisc);
- struct neighbour *mn = dst_get_neighbour(skb_dst(skb));
+ struct teql_sched_data *q = qdisc_priv(txq->qdisc);
struct neighbour *n = q->ncache;
if (mn->tbl == NULL)
@@ -262,17 +262,26 @@ __teql_resolve(struct sk_buff *skb, struct sk_buff *skb_res, struct net_device *
}
static inline int teql_resolve(struct sk_buff *skb,
- struct sk_buff *skb_res, struct net_device *dev)
+ struct sk_buff *skb_res,
+ struct net_device *dev,
+ struct netdev_queue *txq)
{
- struct netdev_queue *txq = netdev_get_tx_queue(dev, 0);
+ struct dst_entry *dst = skb_dst(skb);
+ struct neighbour *mn;
+ int res;
+
if (txq->qdisc == &noop_qdisc)
return -ENODEV;
- if (dev->header_ops == NULL ||
- skb_dst(skb) == NULL ||
- dst_get_neighbour(skb_dst(skb)) == NULL)
+ if (!dev->header_ops || !dst)
return 0;
- return __teql_resolve(skb, skb_res, dev);
+
+ rcu_read_lock();
+ mn = dst_get_neighbour(dst);
+ res = mn ? __teql_resolve(skb, skb_res, dev, txq, mn) : 0;
+ rcu_read_unlock();
+
+ return res;
}
static netdev_tx_t teql_master_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -307,7 +316,7 @@ restart:
continue;
}
- switch (teql_resolve(skb, skb_res, slave)) {
+ switch (teql_resolve(skb, skb_res, slave, slave_txq)) {
case 0:
if (__netif_tx_trylock(slave_txq)) {
unsigned int length = qdisc_pkt_len(skb);
^ permalink raw reply related
* [PATCH 03/12] [MAC802154] mac802154: RX data path
From: Alexander Smirnov @ 2011-11-30 14:23 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111130141827.GA3739-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
Main RX data path implementation between physical and upper layers.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/ieee802154_netdev.h | 2 +
include/net/mac802154.h | 4 ++
net/mac802154/Kconfig | 2 +-
net/mac802154/Makefile | 2 +-
net/mac802154/rx.c | 106 +++++++++++++++++++++++++++++++++++++++
5 files changed, 114 insertions(+), 2 deletions(-)
create mode 100644 net/mac802154/rx.c
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index 5743055..12a7ee4 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -26,6 +26,8 @@
#ifndef IEEE802154_NETDEVICE_H
#define IEEE802154_NETDEVICE_H
+#include <net/af_ieee802154.h>
+
/*
* A control block of skb passed between the ARPHRD_IEEE802154 device
* and other stack parts.
diff --git a/include/net/mac802154.h b/include/net/mac802154.h
index 1b1b1f2..7f6474c 100644
--- a/include/net/mac802154.h
+++ b/include/net/mac802154.h
@@ -143,4 +143,8 @@ struct ieee802154_ops {
int ieee802154_register_device(struct ieee802154_dev *dev);
void ieee802154_unregister_device(struct ieee802154_dev *dev);
+void ieee802154_rx(struct ieee802154_dev *dev, struct sk_buff *skb, u8 lqi);
+void ieee802154_rx_irqsafe(struct ieee802154_dev *dev, struct sk_buff *skb,
+ u8 lqi);
+
#endif /* NET_MAC802154_H */
diff --git a/net/mac802154/Kconfig b/net/mac802154/Kconfig
index 7ab24f8..9ff82e3 100644
--- a/net/mac802154/Kconfig
+++ b/net/mac802154/Kconfig
@@ -9,7 +9,7 @@ config MAC802154
Note: this implementation is neither certified, nor feature
complete! Compatibility with other implementations isn't
- tested!
+ tested yet!
If you plan to use HardMAC IEEE 802.15.4 devices, you can
say N here. Alternatievly you can say M to compile it as
diff --git a/net/mac802154/Makefile b/net/mac802154/Makefile
index cda9393..e00fe47 100644
--- a/net/mac802154/Makefile
+++ b/net/mac802154/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_MAC802154) += mac802154.o
-mac802154-objs := ieee802154_dev.o
+mac802154-objs := ieee802154_dev.o rx.o
diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c
new file mode 100644
index 0000000..1642c48
--- /dev/null
+++ b/net/mac802154/rx.c
@@ -0,0 +1,106 @@
+/*
+ * Copyright (C) 2007-2011 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Written by:
+ * Pavel Smolenskiy <pavel.smolenskiy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ * Maxim Gorbachyov <maxim.gorbachev-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>
+ * Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ * Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/workqueue.h>
+#include <linux/netdevice.h>
+#include <linux/crc-ccitt.h>
+
+#include <net/mac802154.h>
+#include <net/ieee802154_netdev.h>
+
+#include "mac802154.h"
+
+static void
+mac802154_subif_rx(struct ieee802154_dev *hw, struct sk_buff *skb, u8 lqi)
+{
+ struct mac802154_priv *priv = mac802154_to_priv(hw);
+
+ BUG_ON(!skb);
+
+ mac_cb(skb)->lqi = lqi;
+ skb->protocol = htons(ETH_P_IEEE802154);
+ skb_reset_mac_header(skb);
+
+ BUILD_BUG_ON(sizeof(struct ieee802154_mac_cb) > sizeof(skb->cb));
+
+ if (!(priv->hw.flags & IEEE802154_HW_OMIT_CKSUM)) {
+ u16 crc;
+
+ if (skb->len < 2) {
+ pr_debug("(%s): Got invalid frame\n", __func__);
+ goto out;
+ }
+ crc = crc_ccitt(0, skb->data, skb->len);
+ if (crc) {
+ pr_debug("(%s): CRC mismatch\n", __func__);
+ goto out;
+ }
+ skb_trim(skb, skb->len - 2); /* CRC */
+ }
+
+out:
+ dev_kfree_skb(skb);
+ return;
+}
+
+struct rx_work {
+ struct sk_buff *skb;
+ struct work_struct work;
+ struct ieee802154_dev *dev;
+ u8 lqi;
+};
+
+static void mac802154_rx_worker(struct work_struct *work)
+{
+ struct rx_work *rw = container_of(work, struct rx_work, work);
+ struct sk_buff *skb = rw->skb;
+
+ mac802154_subif_rx(rw->dev, skb, rw->lqi);
+ kfree(rw);
+}
+
+void ieee802154_rx_irqsafe(struct ieee802154_dev *dev,
+ struct sk_buff *skb, u8 lqi)
+{
+ struct mac802154_priv *priv = mac802154_to_priv(dev);
+ struct rx_work *work = kzalloc(sizeof(struct rx_work), GFP_ATOMIC);
+
+ if (!work)
+ return;
+
+ INIT_WORK(&work->work, mac802154_rx_worker);
+ work->skb = skb;
+ work->dev = dev;
+ work->lqi = lqi;
+
+ queue_work(priv->dev_workqueue, &work->work);
+}
+EXPORT_SYMBOL(ieee802154_rx_irqsafe);
+
+void mac802154_rx(struct ieee802154_dev *dev, struct sk_buff *skb, u8 lqi)
+{
+ mac802154_subif_rx(dev, skb, lqi);
+}
+EXPORT_SYMBOL(mac802154_rx);
--
1.7.2.3
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
^ permalink raw reply related
* [PATCH 05/12] [IEEE802154] ieee802154: remove ieee802154 policy from globals
From: Alexander Smirnov @ 2011-11-30 14:24 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111130141827.GA3739-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
Move ieee802154_policy array definition inside ieee802154 layer.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/linux/nl802154.h | 2 --
net/ieee802154/ieee802154.h | 2 ++
net/ieee802154/wpan-class.c | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index 33d9f51..d2b5ae2 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -74,8 +74,6 @@ enum {
#define IEEE802154_ATTR_MAX (__IEEE802154_ATTR_MAX - 1)
-extern const struct nla_policy ieee802154_policy[];
-
/* commands */
/* REQ should be responded with CONF
* and INDIC with RESP
diff --git a/net/ieee802154/ieee802154.h b/net/ieee802154/ieee802154.h
index aadec42..e9799af 100644
--- a/net/ieee802154/ieee802154.h
+++ b/net/ieee802154/ieee802154.h
@@ -21,6 +21,8 @@
int __init ieee802154_nl_init(void);
void __exit ieee802154_nl_exit(void);
+extern const struct nla_policy ieee802154_policy[];
+
#define IEEE802154_OP(_cmd, _func) \
{ \
.cmd = _cmd, \
diff --git a/net/ieee802154/wpan-class.c b/net/ieee802154/wpan-class.c
index 1627ef2..36d32e2 100644
--- a/net/ieee802154/wpan-class.c
+++ b/net/ieee802154/wpan-class.c
@@ -21,6 +21,7 @@
#include <linux/module.h>
#include <linux/device.h>
+#include <net/netlink.h>
#include <net/wpan-phy.h>
#include "ieee802154.h"
--
1.7.2.3
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
^ permalink raw reply related
* [PATCH 07/12] [IEEE802154] ieee802154: define simplified mlme interface
From: Alexander Smirnov @ 2011-11-30 14:25 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111130141827.GA3739-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
Define light-weight mlme interface.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/ieee802154_netdev.h | 11 +++++++++++
net/ieee802154/nl-mac.c | 2 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index 12a7ee4..5264b00 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -83,7 +83,12 @@ struct wpan_phy;
* get_phy should increment the reference counting on returned phy.
* Use wpan_wpy_put to put that reference.
*/
+struct simple_mlme_ops {
+ struct wpan_phy *(*get_phy)(const struct net_device *dev);
+};
struct ieee802154_mlme_ops {
+ struct simple_mlme_ops wpan_ops;
+
int (*assoc_req)(struct net_device *dev,
struct ieee802154_addr *addr,
u8 channel, u8 page, u8 cap);
@@ -112,6 +117,12 @@ struct ieee802154_mlme_ops {
u8 (*get_bsn)(const struct net_device *dev);
};
+static inline struct simple_mlme_ops *simple_mlme_ops(
+ const struct net_device *dev)
+{
+ return dev->ml_priv;
+}
+
static inline struct ieee802154_mlme_ops *ieee802154_mlme_ops(
const struct net_device *dev)
{
diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
index adaf462..1d23aa6 100644
--- a/net/ieee802154/nl-mac.c
+++ b/net/ieee802154/nl-mac.c
@@ -263,7 +263,7 @@ static int ieee802154_nl_fill_iface(struct sk_buff *msg, u32 pid,
if (!hdr)
goto out;
- phy = ieee802154_mlme_ops(dev)->get_phy(dev);
+ phy = simple_mlme_ops(dev)->get_phy(dev);
BUG_ON(!phy);
NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
--
1.7.2.3
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
^ permalink raw reply related
* [PATCH 08/12] [MAC802154] mac802154: MAC commands support
From: Alexander Smirnov @ 2011-11-30 14:25 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111130141827.GA3739-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
Support for MAC layer commands. Currently association and
disassociation are implemented only.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/mac802154/Makefile | 2 +-
net/mac802154/mac_cmd.c | 300 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 301 insertions(+), 1 deletions(-)
create mode 100644 net/mac802154/mac_cmd.c
diff --git a/net/mac802154/Makefile b/net/mac802154/Makefile
index 875feb2..50e2569 100644
--- a/net/mac802154/Makefile
+++ b/net/mac802154/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_MAC802154) += mac802154.o
-mac802154-objs := ieee802154_dev.o rx.o tx.o mib.o
+mac802154-objs := ieee802154_dev.o rx.o tx.o mib.o mac_cmd.o
diff --git a/net/mac802154/mac_cmd.c b/net/mac802154/mac_cmd.c
new file mode 100644
index 0000000..0013358
--- /dev/null
+++ b/net/mac802154/mac_cmd.c
@@ -0,0 +1,300 @@
+/*
+ * MAC commands interface
+ *
+ * Copyright 2007, 2008 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Written by:
+ * Sergey Lapin <slapin-9cOl001CZnBAfugRpC6u6w@public.gmane.org>
+ * Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ */
+
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/if_arp.h>
+#include <net/af_ieee802154.h>
+#include <net/mac802154.h>
+#include <net/ieee802154.h>
+#include <net/ieee802154_netdev.h>
+#include <net/nl802154.h>
+
+#include "mac802154.h"
+#include "mib.h"
+
+static int mac802154_cmd_assoc_req(struct sk_buff *skb)
+{
+ u8 cap;
+
+ if (skb->len != 2)
+ return -EINVAL;
+
+ if (skb->pkt_type != PACKET_HOST)
+ return 0;
+
+ if (mac_cb(skb)->sa.addr_type != IEEE802154_ADDR_LONG ||
+ mac_cb(skb)->sa.pan_id != IEEE802154_PANID_BROADCAST)
+ return -EINVAL;
+
+ /*
+ * FIXME: check that we allow incoming ASSOC requests
+ * by consulting MIB
+ */
+
+ cap = skb->data[1];
+
+ return ieee802154_nl_assoc_indic(skb->dev, &mac_cb(skb)->sa, cap);
+}
+
+static int mac802154_cmd_assoc_resp(struct sk_buff *skb)
+{
+ u8 status;
+ u16 short_addr;
+
+ if (skb->len != 4)
+ return -EINVAL;
+
+ if (skb->pkt_type != PACKET_HOST)
+ return 0;
+
+ if (mac_cb(skb)->sa.addr_type != IEEE802154_ADDR_LONG ||
+ mac_cb(skb)->sa.addr_type != IEEE802154_ADDR_LONG ||
+ !(mac_cb(skb)->flags & MAC_CB_FLAG_INTRAPAN))
+ return -EINVAL;
+
+ /* FIXME: check that we requested association ? */
+
+ status = skb->data[3];
+ short_addr = skb->data[1] | (skb->data[2] << 8);
+ pr_info("Received ASSOC-RESP status %x, addr %hx\n", status,
+ short_addr);
+ if (status) {
+ mac802154_dev_set_short_addr(skb->dev,
+ IEEE802154_ADDR_BROADCAST);
+ mac802154_dev_set_pan_id(skb->dev,
+ IEEE802154_PANID_BROADCAST);
+ } else
+ mac802154_dev_set_short_addr(skb->dev, short_addr);
+
+ return ieee802154_nl_assoc_confirm(skb->dev, short_addr, status);
+}
+
+static int mac802154_cmd_disassoc_notify(struct sk_buff *skb)
+{
+ u8 reason;
+
+ if (skb->len != 2)
+ return -EINVAL;
+
+ if (skb->pkt_type != PACKET_HOST)
+ return 0;
+
+ if (mac_cb(skb)->sa.addr_type != IEEE802154_ADDR_LONG ||
+ (mac_cb(skb)->da.addr_type != IEEE802154_ADDR_LONG &&
+ mac_cb(skb)->da.addr_type != IEEE802154_ADDR_SHORT) ||
+ mac_cb(skb)->sa.pan_id != mac_cb(skb)->da.pan_id)
+ return -EINVAL;
+
+ reason = skb->data[1];
+
+ /* FIXME: checks if this was our coordinator and the disassoc us */
+ /* FIXME: if we device, one should receive ->da and not ->sa */
+ /* FIXME: the status should also help */
+
+ return ieee802154_nl_disassoc_indic(skb->dev, &mac_cb(skb)->sa,
+ reason);
+}
+
+int mac802154_process_cmd(struct net_device *dev, struct sk_buff *skb)
+{
+ u8 cmd;
+
+ if (skb->len < 1) {
+ pr_warning("Uncomplete command frame!\n");
+ goto drop;
+ }
+
+ cmd = *(skb->data);
+ pr_debug("(%s): command %02x on device %s\n",
+ __func__, cmd, dev->name);
+
+ switch (cmd) {
+ case IEEE802154_CMD_ASSOCIATION_REQ:
+ mac802154_cmd_assoc_req(skb);
+ break;
+ case IEEE802154_CMD_ASSOCIATION_RESP:
+ mac802154_cmd_assoc_resp(skb);
+ break;
+ case IEEE802154_CMD_DISASSOCIATION_NOTIFY:
+ mac802154_cmd_disassoc_notify(skb);
+ break;
+ case IEEE802154_CMD_BEACON_REQ:
+ default:
+ pr_debug("(%s): frame type is not supported yet\n", __func__);
+ goto drop;
+ }
+
+
+ kfree_skb(skb);
+ return NET_RX_SUCCESS;
+
+drop:
+ kfree_skb(skb);
+ return NET_RX_DROP;
+}
+
+static int mac802154_send_cmd(struct net_device *dev,
+ struct ieee802154_addr *addr, struct ieee802154_addr *saddr,
+ const u8 *buf, int len)
+{
+ struct sk_buff *skb;
+ int err;
+ int hlen = LL_RESERVED_SPACE(dev), tlen = dev->needed_tailroom;
+
+ BUG_ON(dev->type != ARPHRD_IEEE802154);
+
+ skb = alloc_skb(hlen + tlen + len, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ skb_reserve(skb, hlen);
+
+ skb_reset_network_header(skb);
+
+ mac_cb(skb)->flags = IEEE802154_FC_TYPE_MAC_CMD | MAC_CB_FLAG_ACKREQ;
+ mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
+ err = dev_hard_header(skb, dev, ETH_P_IEEE802154, addr, saddr, len);
+ if (err < 0) {
+ kfree_skb(skb);
+ return err;
+ }
+
+ skb_reset_mac_header(skb);
+ memcpy(skb_put(skb, len), buf, len);
+
+ skb->dev = dev;
+ skb->protocol = htons(ETH_P_IEEE802154);
+
+ return dev_queue_xmit(skb);
+}
+
+static int mac802154_mlme_assoc_req(struct net_device *dev,
+ struct ieee802154_addr *addr, u8 channel, u8 page, u8 cap)
+{
+ struct ieee802154_addr saddr;
+ u8 buf[2];
+ int pos = 0;
+
+ saddr.addr_type = IEEE802154_ADDR_LONG;
+ saddr.pan_id = IEEE802154_PANID_BROADCAST;
+ memcpy(saddr.hwaddr, dev->dev_addr, IEEE802154_ADDR_LEN);
+
+
+ /* FIXME: set PIB/MIB info */
+ mac802154_dev_set_pan_id(dev, addr->pan_id);
+ mac802154_dev_set_page_channel(dev, page, channel);
+ mac802154_dev_set_ieee_addr(dev);
+
+ buf[pos++] = IEEE802154_CMD_ASSOCIATION_REQ;
+ buf[pos++] = cap;
+
+ return mac802154_send_cmd(dev, addr, &saddr, buf, pos);
+}
+
+static int mac802154_mlme_assoc_resp(struct net_device *dev,
+ struct ieee802154_addr *addr, u16 short_addr, u8 status)
+{
+ struct ieee802154_addr saddr;
+ u8 buf[4];
+ int pos = 0;
+
+ saddr.addr_type = IEEE802154_ADDR_LONG;
+ saddr.pan_id = addr->pan_id;
+ memcpy(saddr.hwaddr, dev->dev_addr, IEEE802154_ADDR_LEN);
+
+ buf[pos++] = IEEE802154_CMD_ASSOCIATION_RESP;
+ buf[pos++] = short_addr;
+ buf[pos++] = short_addr >> 8;
+ buf[pos++] = status;
+
+ return mac802154_send_cmd(dev, addr, &saddr, buf, pos);
+}
+
+static int mac802154_mlme_disassoc_req(struct net_device *dev,
+ struct ieee802154_addr *addr, u8 reason)
+{
+ struct ieee802154_addr saddr;
+ u8 buf[2];
+ int pos = 0;
+ int ret;
+
+ saddr.addr_type = IEEE802154_ADDR_LONG;
+ saddr.pan_id = addr->pan_id;
+ memcpy(saddr.hwaddr, dev->dev_addr, IEEE802154_ADDR_LEN);
+
+ buf[pos++] = IEEE802154_CMD_DISASSOCIATION_NOTIFY;
+ buf[pos++] = reason;
+
+ ret = mac802154_send_cmd(dev, addr, &saddr, buf, pos);
+
+ /* FIXME: this should be after the ack receved */
+ mac802154_dev_set_pan_id(dev, 0xffff);
+ mac802154_dev_set_short_addr(dev, 0xffff);
+ ieee802154_nl_disassoc_confirm(dev, 0x00);
+
+ return ret;
+}
+
+static int mac802154_mlme_start_req(struct net_device *dev,
+ struct ieee802154_addr *addr,
+ u8 channel, u8 page,
+ u8 bcn_ord, u8 sf_ord, u8 pan_coord, u8 blx,
+ u8 coord_realign)
+{
+ BUG_ON(addr->addr_type != IEEE802154_ADDR_SHORT);
+
+ mac802154_dev_set_pan_id(dev, addr->pan_id);
+ mac802154_dev_set_short_addr(dev, addr->short_addr);
+ mac802154_dev_set_ieee_addr(dev);
+ mac802154_dev_set_page_channel(dev, page, channel);
+
+ /*
+ * FIXME: add validation for unused parameters to be sane
+ * for SoftMAC
+ */
+
+ if (pan_coord)
+ dev->priv_flags |= IFF_IEEE802154_COORD;
+ else
+ dev->priv_flags &= ~IFF_IEEE802154_COORD;
+
+ mac802154_dev_set_pan_coord(dev);
+ ieee802154_nl_start_confirm(dev, IEEE802154_SUCCESS);
+
+ return 0;
+}
+
+struct ieee802154_mlme_ops mac802154_mlme_wpan = {
+ .assoc_req = mac802154_mlme_assoc_req,
+ .assoc_resp = mac802154_mlme_assoc_resp,
+ .disassoc_req = mac802154_mlme_disassoc_req,
+ .start_req = mac802154_mlme_start_req,
+
+ .wpan_ops.get_phy = mac802154_get_phy,
+
+ .get_pan_id = mac802154_dev_get_pan_id,
+ .get_short_addr = mac802154_dev_get_short_addr,
+ .get_dsn = mac802154_dev_get_dsn,
+ .get_bsn = mac802154_dev_get_bsn,
+};
--
1.7.2.3
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
^ permalink raw reply related
* [PATCH 10/12] [MAC802154] mac802154: bind network iface to phy
From: Alexander Smirnov @ 2011-11-30 14:27 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111130141827.GA3739-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
Transciever slaves manipulation. Each slave represents network interface
in user space and is described by net_device structure. One transciever
may support several slaves and be connected to several networks at the
same time.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/mac802154/ieee802154_dev.c | 147 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/net/mac802154/ieee802154_dev.c b/net/mac802154/ieee802154_dev.c
index e90d336..8fe1a9b 100644
--- a/net/mac802154/ieee802154_dev.c
+++ b/net/mac802154/ieee802154_dev.c
@@ -18,12 +18,143 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
+#include <linux/nl802154.h>
#include <net/route.h>
#include <net/mac802154.h>
#include <net/wpan-phy.h>
#include "mac802154.h"
+#include "mib.h"
+
+int mac802154_slave_open(struct net_device *dev)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+ int res = 0;
+
+ if (priv->hw->open_count++ == 0) {
+ res = priv->hw->ops->start(&priv->hw->hw);
+ WARN_ON(res);
+ if (res)
+ goto err;
+ }
+
+ if (priv->hw->ops->ieee_addr) {
+ res = priv->hw->ops->ieee_addr(&priv->hw->hw, dev->dev_addr);
+ WARN_ON(res);
+ if (res)
+ goto err;
+ mac802154_dev_set_ieee_addr(dev);
+ }
+
+ netif_start_queue(dev);
+ return 0;
+err:
+ priv->hw->open_count--;
+
+ return res;
+}
+
+int mac802154_slave_close(struct net_device *dev)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+
+ dev->priv_flags &= ~IFF_IEEE802154_COORD;
+
+ netif_stop_queue(dev);
+
+ if ((--priv->hw->open_count) == 0)
+ priv->hw->ops->stop(&priv->hw->hw);
+
+ return 0;
+}
+
+static int mac802154_netdev_register(struct wpan_phy *phy,
+ struct net_device *dev)
+{
+ struct mac802154_sub_if_data *priv;
+ struct mac802154_priv *ipriv;
+ int err;
+
+ ipriv = wpan_phy_priv(phy);
+
+ priv = netdev_priv(dev);
+ priv->dev = dev;
+ priv->hw = ipriv;
+
+ dev->needed_headroom = ipriv->hw.extra_tx_headroom;
+
+ SET_NETDEV_DEV(dev, &ipriv->phy->dev);
+
+ mutex_lock(&ipriv->slaves_mtx);
+ if (!ipriv->running) {
+ mutex_unlock(&ipriv->slaves_mtx);
+ return -ENODEV;
+ }
+ mutex_unlock(&ipriv->slaves_mtx);
+
+ err = register_netdev(dev);
+ if (err < 0)
+ return err;
+
+ rtnl_lock();
+ mutex_lock(&ipriv->slaves_mtx);
+ list_add_tail_rcu(&priv->list, &ipriv->slaves);
+ mutex_unlock(&ipriv->slaves_mtx);
+ rtnl_unlock();
+
+ return 0;
+}
+
+static void mac802154_del_iface(struct wpan_phy *phy,
+ struct net_device *dev)
+{
+ struct mac802154_sub_if_data *sdata;
+ ASSERT_RTNL();
+
+ sdata = netdev_priv(dev);
+
+ BUG_ON(sdata->hw->phy != phy);
+
+ mutex_lock(&sdata->hw->slaves_mtx);
+ list_del_rcu(&sdata->list);
+ mutex_unlock(&sdata->hw->slaves_mtx);
+
+ synchronize_rcu();
+ unregister_netdevice(sdata->dev);
+}
+
+static struct net_device *mac802154_add_iface(struct wpan_phy *phy,
+ const char *name, int type)
+{
+ struct net_device *dev;
+ int err = -ENOMEM;
+
+ /* No devices is currently supported */
+ switch (type) {
+ default:
+ dev = NULL;
+ err = -EINVAL;
+ break;
+ }
+ if (!dev)
+ goto err;
+
+
+ err = mac802154_netdev_register(phy, dev);
+
+ if (err)
+ goto err_free;
+
+ dev_hold(dev); /* we return a device w/ incremented refcount */
+ return dev;
+
+err_free:
+ free_netdev(dev);
+err:
+ return ERR_PTR(err);
+}
+
struct ieee802154_dev *ieee802154_alloc_device(size_t priv_size,
struct ieee802154_ops *ops)
@@ -61,6 +192,8 @@ void ieee802154_free_device(struct ieee802154_dev *hw)
{
struct mac802154_priv *priv = mac802154_to_priv(hw);
+ BUG_ON(!list_empty(&priv->slaves));
+
wpan_phy_free(priv->phy);
mutex_destroy(&priv->slaves_mtx);
@@ -80,6 +213,9 @@ int ieee802154_register_device(struct ieee802154_dev *dev)
wpan_phy_set_dev(priv->phy, priv->hw.parent);
+ priv->phy->add_iface = mac802154_add_iface;
+ priv->phy->del_iface = mac802154_del_iface;
+
rc = wpan_phy_register(priv->phy);
if (rc < 0)
goto out_wq;
@@ -99,9 +235,12 @@ out:
}
EXPORT_SYMBOL(ieee802154_register_device);
+
+
void ieee802154_unregister_device(struct ieee802154_dev *dev)
{
struct mac802154_priv *priv = mac802154_to_priv(dev);
+ struct mac802154_sub_if_data *sdata, *next;
flush_workqueue(priv->dev_workqueue);
destroy_workqueue(priv->dev_workqueue);
@@ -112,6 +251,14 @@ void ieee802154_unregister_device(struct ieee802154_dev *dev)
priv->running = 0;
mutex_unlock(&priv->slaves_mtx);
+ list_for_each_entry_safe(sdata, next, &priv->slaves, list) {
+ mutex_lock(&sdata->hw->slaves_mtx);
+ list_del(&sdata->list);
+ mutex_unlock(&sdata->hw->slaves_mtx);
+
+ unregister_netdevice(sdata->dev);
+ }
+
rtnl_unlock();
wpan_phy_unregister(priv->phy);
--
1.7.2.3
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
^ permalink raw reply related
* [PATCH v3] net: fec: Select the FEC driver by default for i.MX SoCs
From: Fabio Estevam @ 2011-11-30 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Fabio Estevam, netdev, marek.vasut, kernel, u.kleine-koenig,
davem, shawn.guo
In-Reply-To: <1322652717-2685-1-git-send-email-fabio.estevam@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]
Since commit 230dec6 (net/fec: add imx6q enet support) the FEC driver is no
longer built by default for i.MX SoCs.
Let the FEC driver be built by default again.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Acked-by: Shawn Guo <shawn.guo@linaro.org>
---
Changes since v2:
- Improve commit message
- Reorder the placement of the "default" line
Changes since v1:
Move the FEC selection into Kconfig instead of .config file
drivers/net/ethernet/freescale/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index c520cfd..5272f9d 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -24,6 +24,7 @@ config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
ARCH_MXC || ARCH_MXS)
+ default ARCH_MXC || ARCH_MXS if ARM
select PHYLIB
---help---
Say Y here if you want to use the built-in 10/100 Fast ethernet
--
1.7.1
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH for-3.2] tools/virtio: add module.h stub
From: Michael S. Tsirkin @ 2011-11-30 14:46 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-kernel
make it build with linux 3.2
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
tools/virtio/linux/module.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 tools/virtio/linux/module.h
diff --git a/tools/virtio/linux/module.h b/tools/virtio/linux/module.h
new file mode 100644
index 0000000..96868eb
--- /dev/null
+++ b/tools/virtio/linux/module.h
@@ -0,0 +1,3 @@
+#ifndef LINUX_MODULE_H
+#define LINUX_MODULE_H
+#endif
--
1.7.5.53.gc233e
^ permalink raw reply related
* Re: [Linux-decnet-user] Proposed removal of DECnet support (was:Re: [BUG] 3.2-rc2:BUG kmalloc-8: Redzone overwritten)
From: Steven Whitehouse @ 2011-11-30 14:52 UTC (permalink / raw)
To: mike.gair
Cc: Philipp Schafft, Chrissie Caulfield, Christoph Lameter,
David Miller, Eric Dumazet, Sasha Levin, Linux-DECnet user,
linux-kernel, linux-mm, Matt Mackall, netdev, Pekka Enberg,
RoarAudio
In-Reply-To: <OF7785CDCC.246C1F8F-ON80257958.004A9A89-80257958.004C103D@LocalDomain>
Hi,
On Wed, 2011-11-30 at 13:52 +0000, mike.gair@tatasteel.com wrote:
> We're using decnet on linux,
> as a way of expanding a control system,
> using DEC PDP11s (actually charon11 emulations).
>
> So woud be very interested in keeping decnet supported.
>
> In theory i'd be interested in maintaining it,
> but i'm not sure what amount of work is involved,
> have no experience of kernel, or where to start.
>
> Any ideas?
>
>
So the issue is basically that due to there being nobody currently
maintaining the DECnet stack, it puts a burden on the core network
maintainers when they make cross-protocol changes, as they have to
figure out what impact the changes are likely to have on the DECnet
stack. So its an extra barrier to making cross-protocol code changes.
If there was an active maintainer who could be a source of knowledge
(and the odd patch to help out making those changes) then this issue
would largely go away.
The most important duty of the maintainer is just to watch whats going
on in the core networking development and to contribute the DECnet part
of that. So it would be most likely be more a reviewing of patches and
providing advice role, than one of writing patches (though it could be
that too) and ensuring that the code continues to function correctly by
testing it from time to time.
The ideal maintainer would have an in-depth knowledge of the core Linux
networking stack (socket layer, dst and neigh code), the DECnet specs
and have a good knowledge of C.
Bearing in mind the low patch volume (almost zero, except for core
stuff), it would probably be one of the subsystems with the least amount
of work to do in maintaining it. So in some ways, a good intro for a new
maintainer.
I do try and keep an eye on what get submitted to the DECnet code and
I'll continue to do that while it is still in the kernel. However, it is
now quite a long time since I last did any substantial work in the
networking area and things have moved on a fair bit in the mean time. I
don't have a lot of time to review DECnet patches these days and no way
to actually test any contributions against a real DECnet implementation.
So I'll provide what help I can to anybody who wants to take the role
on, within those limitations. I'm also happy to answer questions about
why things were done in a particular way, for example.
It is good to know that people are still using the Linux DECnet code
too. It has lived far beyond the time when I'd envisioned it still being
useful :-)
Steve.
>
>
>
> Philipp Schafft <lion@lion.leolix.org> wrote on 29/11/2011 14:47:19:
>
> > reflum,
> >
> > On Tue, 2011-11-29 at 15:34 +0100, Steven Whitehouse wrote:
> >
> > > Has anybody actually tested it
> > > > >> lately against "real" DEC implementations?
> > > > > I doubt it :-)
> > > > DECnet is in use against real DEC implementations - I have
> checked it
> > > > quite recently against a VAX running OpenVMS. How many people
> are
> > > > actually using it for real work is a different question though.
> > > >
> > > Ok, thats useful info.
> >
> > I confirmed parts of it with tcpdump and the specs some weeks ago.
> The
> > parts I worked on passed :) I also considered to send the tcpdump
> > upstream a patch for protocol decoding.
> >
> >
> > > > It's also true that it's not really supported by anyone as I
> orphaned it
> > > > some time ago and nobody else seems to care enough to take it
> over. So
> > > > if it's becoming a burden on people doing real kernel work then
> I don't
> > > > think many tears will be wept for its removal.
> > > > Chrissie
> > >
> > > Really the only issue with keeping it around is the maintenance
> burden I
> > > think. It doesn't look like anybody wants to take it on, but maybe
> we
> > > should give it another few days for someone to speak up, just in
> case
> > > they are on holiday or something at the moment.
> > >
> > > Also, I've updated the subject of the thread, to make it more
> obvious
> > > what is being discussed, as well as bcc'ing it again to the DECnet
> list,
> >
> > I'm very interested in the module. However my problem is that I had
> > nothing to do with kernel coding yet. However I'm currently
> searching a
> > new maintainer for it (I got info about this thread by today).
> > If somebody is interested in this and only needs some "motivation"
> or
> > maybe someone would like to get me into kernel coding, please just
> > reply :)
> >
> > --
> > Philipp.
> > (Rah of PH2)
> > [attachment "signature.asc" deleted by Mike Gair/UK/Corus]
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > Project Home Page: http://linux-decnet.wiki.sourceforge.net/
> >
> > Linux-decnet-user mailing list
> > Linux-decnet-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-decnet-user
> >
>
>
> **********************************************************************
> This transmission is confidential and must not be used or disclosed by
> anyone other than the intended recipient. Neither Tata Steel Europe
> Limited nor any of its subsidiaries can accept any responsibility for
> any use or misuse of the transmission by anyone.
>
> For address and company registration details of certain entities
> within the Tata Steel Europe group of companies, please visit
> http://www.tatasteeleurope.com/entities
> **********************************************************************
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 2/2] net/hyperv: Add support for promiscuous mode setting
From: Haiyang Zhang @ 2011-11-30 15:19 UTC (permalink / raw)
To: haiyangz, kys, davem, gregkh, linux-kernel, netdev, devel
In-Reply-To: <1322666348-6554-1-git-send-email-haiyangz@microsoft.com>
Add code to accept promiscuous mode setting, and pass it to
RNDIS filter.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/hyperv_net.h | 24 +++++++++++++++++++
drivers/net/hyperv/netvsc_drv.c | 46 ++++++++++++++++++++++++++++++++++--
drivers/net/hyperv/rndis_filter.c | 23 +-----------------
3 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index ac1ec84..49b131f 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -87,6 +87,27 @@ struct netvsc_device_info {
int ring_size;
};
+enum rndis_device_state {
+ RNDIS_DEV_UNINITIALIZED = 0,
+ RNDIS_DEV_INITIALIZING,
+ RNDIS_DEV_INITIALIZED,
+ RNDIS_DEV_DATAINITIALIZED,
+};
+
+struct rndis_device {
+ struct netvsc_device *net_dev;
+
+ enum rndis_device_state state;
+ bool link_state;
+ atomic_t new_req_id;
+
+ spinlock_t request_lock;
+ struct list_head req_list;
+
+ unsigned char hw_mac_adr[ETH_ALEN];
+};
+
+
/* Interface */
int netvsc_device_add(struct hv_device *device, void *additional_info);
int netvsc_device_remove(struct hv_device *device);
@@ -109,6 +130,9 @@ int rndis_filter_receive(struct hv_device *dev,
int rndis_filter_send(struct hv_device *dev,
struct hv_netvsc_packet *pkt);
+int rndis_filter_set_packet_filter(struct rndis_device *dev, u32 new_filter);
+
+
#define NVSP_INVALID_PROTOCOL_VERSION ((u32)0xFFFFFFFF)
#define NVSP_PROTOCOL_VERSION_1 2
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 93b0e91..b69c3a4 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -56,11 +56,51 @@ static int ring_size = 128;
module_param(ring_size, int, S_IRUGO);
MODULE_PARM_DESC(ring_size, "Ring buffer size (# of pages)");
-/* no-op so the netdev core doesn't return -EINVAL when modifying the the
- * multicast address list in SIOCADDMULTI. hv is setup to get all multicast
- * when it calls RndisFilterOnOpen() */
+struct set_multicast_work {
+ struct work_struct work;
+ struct net_device *net;
+};
+
+static void do_set_multicast(struct work_struct *w)
+{
+ struct set_multicast_work *swk =
+ container_of(w, struct set_multicast_work, work);
+ struct net_device *net = swk->net;
+
+ struct net_device_context *ndevctx = netdev_priv(net);
+ struct netvsc_device *nvdev;
+ struct rndis_device *rdev;
+
+ nvdev = hv_get_drvdata(ndevctx->device_ctx);
+ if (nvdev == NULL)
+ return;
+
+ rdev = nvdev->extension;
+ if (rdev == NULL)
+ return;
+
+ if (net->flags & IFF_PROMISC)
+ rndis_filter_set_packet_filter(rdev,
+ NDIS_PACKET_TYPE_PROMISCUOUS);
+ else
+ rndis_filter_set_packet_filter(rdev,
+ NDIS_PACKET_TYPE_BROADCAST |
+ NDIS_PACKET_TYPE_ALL_MULTICAST |
+ NDIS_PACKET_TYPE_DIRECTED);
+
+ kfree(w);
+}
+
static void netvsc_set_multicast_list(struct net_device *net)
{
+ struct set_multicast_work *swk =
+ kmalloc(sizeof(struct set_multicast_work), GFP_ATOMIC);
+ if (swk == NULL)
+ return;
+
+ swk->net = net;
+ INIT_WORK(&swk->work, do_set_multicast);
+ schedule_work(&swk->work);
}
static int netvsc_open(struct net_device *net)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index bafccb3..418e7aa 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -30,26 +30,6 @@
#include "hyperv_net.h"
-enum rndis_device_state {
- RNDIS_DEV_UNINITIALIZED = 0,
- RNDIS_DEV_INITIALIZING,
- RNDIS_DEV_INITIALIZED,
- RNDIS_DEV_DATAINITIALIZED,
-};
-
-struct rndis_device {
- struct netvsc_device *net_dev;
-
- enum rndis_device_state state;
- bool link_state;
- atomic_t new_req_id;
-
- spinlock_t request_lock;
- struct list_head req_list;
-
- unsigned char hw_mac_adr[ETH_ALEN];
-};
-
struct rndis_request {
struct list_head list_ent;
struct completion wait_event;
@@ -522,8 +502,7 @@ static int rndis_filter_query_device_link_status(struct rndis_device *dev)
return ret;
}
-static int rndis_filter_set_packet_filter(struct rndis_device *dev,
- u32 new_filter)
+int rndis_filter_set_packet_filter(struct rndis_device *dev, u32 new_filter)
{
struct rndis_request *request;
struct rndis_set_request *set;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] net/hyperv: Fix long lines in netvsc.c
From: Haiyang Zhang @ 2011-11-30 15:19 UTC (permalink / raw)
To: haiyangz, kys, davem, gregkh, linux-kernel, netdev, devel
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/netvsc.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 28e69a6..4a807e4 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -230,9 +230,11 @@ static int netvsc_init_recv_buf(struct hv_device *device)
net_device->recv_section_cnt = init_packet->msg.
v1_msg.send_recv_buf_complete.num_sections;
- net_device->recv_section = kmemdup(init_packet->msg.v1_msg.send_recv_buf_complete.sections,
- net_device->recv_section_cnt * sizeof(struct nvsp_1_receive_buffer_section),
- GFP_KERNEL);
+ net_device->recv_section = kmemdup(
+ init_packet->msg.v1_msg.send_recv_buf_complete.sections,
+ net_device->recv_section_cnt *
+ sizeof(struct nvsp_1_receive_buffer_section),
+ GFP_KERNEL);
if (net_device->recv_section == NULL) {
ret = -EINVAL;
goto cleanup;
--
1.7.4.1
^ permalink raw reply related
* Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Patrick McHardy @ 2011-11-30 15:27 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Pablo Neira Ayuso, jengelh, netfilter-devel, netdev,
hans.schillstrom
In-Reply-To: <hr62jai.42522fc2b4c8846204d05566f5c6b926@obelix.schillstrom.com>
On 11/28/2011 10:36 AM, Hans Schillstrom wrote:
>> If you don't want to use conntrack in your setup and you want to handle
>> fragments, then you have to configure HMARK to calculate the hashing
>> based on the network addresses. If you want to fully support fragments,
>> then enable conntrack and you can configure HMARK to calculate the
>> hashing based on network address + transport bits.
>>
>> Fix this by removing the fragmentation handling, then assume that
>> people can select between two hashing configuration for HMARK. One
>> based for network address which is fragment-safe, one that uses the
>> transport layer information, that requires conntrack. Otherwise, I
>> don't see a sane way to handle this situation.
> Correct me if I'm wrong here,
> If conntrack is enabled hmark don't see the packet until it is reassembled and
> in that case the fragmentation header is removed.
>
> So, with conntrack HMARK will operate on full packets not fragments
> without conntrack ports will not be used on any fragment
Correct.
You don't necessarily need conntrack for defragmentation though,
we've moved defragmentation to a seperate module for TPROXY. You
can depend on that and get defragmentation without full
connection tracking.
^ permalink raw reply
* Re: Integration of Open vSwitch
From: Herbert Xu @ 2011-11-30 15:47 UTC (permalink / raw)
To: jhs
Cc: Jesse Gross, netdev, dev, David Miller, Stephen Hemminger,
Chris Wright, John Fastabend, Eric Dumazet
In-Reply-To: <1322661715.2243.33.camel@mojatatu>
On Wed, Nov 30, 2011 at 09:01:55AM -0500, jamal wrote:
>
> Ah yes, them locks. Unless you start doing per-cpu tables
> with lazy synchronization i am not sure how to avoid that.
> Note: last time (time flies) i compared against iptables, the tc flow
> setup/teardown was pretty consistent regardless of table size
> relatively speaking.
iptables sets a pretty low bar :)
For a flow cache I think going per-cpu or at least per-node will
be unavoidable.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Patrick McHardy @ 2011-11-30 15:51 UTC (permalink / raw)
To: Hans Schillstrom
Cc: pablo, jengelh, netfilter-devel, netdev, hans.schillstrom
In-Reply-To: <1322213787-25796-2-git-send-email-hans@schillstrom.com>
On 11/25/2011 10:36 AM, Hans Schillstrom wrote:
> +__u32 hmark_v6(struct sk_buff *skb, const struct xt_action_param *par)
> +{
> + struct xt_hmark_info *info = (struct xt_hmark_info *)par->targinfo;
> + int nhoff, poff, hdrlen;
> + u32 addr1, addr2, hash;
> + struct ipv6hdr *ip6;
> + u8 nexthdr;
> + int frag = 0, ip6hdrlvl = 0; /* Header level */
> + struct ipv6_opt_hdr _hdr, *hp;
> + union {
> + u32 v32;
> + u16 v16[2];
> + } ports;
> +
> + ports.v32 = 0;
> + nhoff = skb_network_offset(skb);
> +
> +hdr_new:
> + /* Get header info */
> + ip6 = (struct ipv6hdr *) (skb->data + nhoff);
> + nexthdr = ip6->nexthdr;
> + hdrlen = sizeof(struct ipv6hdr);
> + hp = skb_header_pointer(skb, nhoff + hdrlen, sizeof(_hdr),&_hdr);
> +
> + while (nexthdr) {
> + switch (nexthdr) {
> + case IPPROTO_ICMPV6:
> + /* ICMP Error then move ptr to inner header */
> + if (get_inner6_hdr(skb,&nhoff, hdrlen)) {
This doesn't look right. You assume the ICMPv6 header is following
the IPv6 header with any other headers in between. If there are
other headers, hdrlen will contain the length of the last header.
> + ip6hdrlvl++;
> + if (!pskb_may_pull(skb, sizeof(_hdr) + nhoff))
> + return XT_CONTINUE;
> + goto hdr_new;
> + }
> + nhoff += hdrlen;
> + goto hdr_rdy;
> +
> + case NEXTHDR_FRAGMENT:
> + if (!ip6hdrlvl) /* Do not use ports if fragmented */
> + frag = 1;
Shouldn't you also check for fragment offset == 0 here?
The fragment header also doesn't include the length, so
using ipv6_optlen() below is incorrect.
> + break;
> +
> + /* End of hdr traversing cont. with ports and hash calc. */
> + case NEXTHDR_IPV6: /* Do not process tunnels */
That comment looks misleading, you do seem to process them?
> + case NEXTHDR_TCP:
> + case NEXTHDR_UDP:
> + case NEXTHDR_ESP:
> + case NEXTHDR_AUTH:
Don't you want to use the port numbers if only authentication
without encryption is used?
> + case NEXTHDR_SCTP:
> + case NEXTHDR_NONE: /* Last hdr of something unknown */
> + nhoff += hdrlen;
> + goto hdr_rdy;
> + default:
> + return XT_CONTINUE;
> + }
> + if (!hp)
> + return XT_CONTINUE;
> + nhoff += hdrlen; /* eat current header */
> + nexthdr = hp->nexthdr; /* Next header */
> + hdrlen = ipv6_optlen(hp);
> + hp = skb_header_pointer(skb, nhoff + hdrlen, sizeof(_hdr),
> + &_hdr);
> +
> + if (!pskb_may_pull(skb, nhoff))
> + return XT_CONTINUE;
> + }
And final question, why not simply use ipv6_skip_exthdr()?
> +hdr_rdy:
> +...
^ permalink raw reply
* Re: [PATCH 04/12] [MAC802154] mac802154: TX data path
From: Dmitry Eremin-Solenikov @ 2011-11-30 15:56 UTC (permalink / raw)
To: Alexander Smirnov; +Cc: linux-zigbee-devel, netdev, davem
In-Reply-To: <1322663029-3880-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Hello,
On Wed, Nov 30, 2011 at 6:23 PM, Alexander Smirnov
<alex.bluesman.smirnov@gmail.com> wrote:
> Main TX data path implementation between upper and physical layers.
>
> Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
> ---
> net/mac802154/Makefile | 2 +-
> net/mac802154/ieee802154_dev.c | 3 +-
> net/mac802154/tx.c | 102 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 105 insertions(+), 2 deletions(-)
> create mode 100644 net/mac802154/tx.c
>
> diff --git a/net/mac802154/Makefile b/net/mac802154/Makefile
> index e00fe47..490beef 100644
> --- a/net/mac802154/Makefile
> +++ b/net/mac802154/Makefile
> @@ -1,2 +1,2 @@
> obj-$(CONFIG_MAC802154) += mac802154.o
> -mac802154-objs := ieee802154_dev.o rx.o
> +mac802154-objs := ieee802154_dev.o rx.o tx.o
> diff --git a/net/mac802154/ieee802154_dev.c b/net/mac802154/ieee802154_dev.c
> index 42f95b2..e90d336 100644
> --- a/net/mac802154/ieee802154_dev.c
> +++ b/net/mac802154/ieee802154_dev.c
> @@ -31,7 +31,8 @@ struct ieee802154_dev *ieee802154_alloc_device(size_t priv_size,
> struct wpan_phy *phy;
> struct mac802154_priv *priv;
>
> - if (!ops || !ops->xmit || !ops->ed || !ops->start || !ops->stop) {
> + if (!ops || !ops->xmit || !ops->ed || !ops->start || !ops->stop ||
> + !ops->set_channel) {
> printk(KERN_ERR
> "Undefined IEEE802.15.4 device operations\n");
> return NULL;
Shan't this be present in one of the previous patches instead? Because
it's illogical to include the check here and not before, if you define
set_channel
operation in previous patch.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 06/12] [MAC802154] mac802154: MIB support
From: Dmitry Eremin-Solenikov @ 2011-11-30 16:00 UTC (permalink / raw)
To: Alexander Smirnov; +Cc: linux-zigbee-devel, netdev, davem
In-Reply-To: <1322663105-3952-1-git-send-email-alex.bluesman.smirnov@gmail.com>
Hello,
On Wed, Nov 30, 2011 at 6:25 PM, Alexander Smirnov
<alex.bluesman.smirnov@gmail.com> wrote:
> Support for IEEE 802.15.4 management information base,
> routine like setting of HW address, PAN id, channel etc...
>
> Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
> ---
> include/linux/if.h | 3 +
> net/mac802154/Makefile | 2 +-
> net/mac802154/mac802154.h | 22 ++++
> net/mac802154/mib.c | 247 +++++++++++++++++++++++++++++++++++++++++++++
> net/mac802154/mib.h | 35 +++++++
> 5 files changed, 308 insertions(+), 1 deletions(-)
> create mode 100644 net/mac802154/mib.c
> create mode 100644 net/mac802154/mib.h
>
> diff --git a/include/linux/if.h b/include/linux/if.h
> index 06b6ef6..deaf14c 100644
> --- a/include/linux/if.h
> +++ b/include/linux/if.h
> @@ -76,6 +76,9 @@
> #define IFF_BRIDGE_PORT 0x4000 /* device used as bridge port */
> #define IFF_OVS_DATAPATH 0x8000 /* device used as Open vSwitch
> * datapath port */
> +
> +#define IFF_IEEE802154_COORD 0x400 /* IEEE802.15.4 PAN coordinator */
> +
I remember this define, but I don't remember why we did it this way.
Is it suitable
to use this namespace for device-specific flags?
> #define IFF_TX_SKB_SHARING 0x10000 /* The interface supports sharing
> * skbs on transmit */
> #define IFF_UNICAST_FLT 0x20000 /* Supports unicast filtering */
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [MAC802154] DRAFT: IEEE 802.15.4 MAC layer basic implementation
From: Dmitry Eremin-Solenikov @ 2011-11-30 16:13 UTC (permalink / raw)
To: Alexander Smirnov, Jon Smirl; +Cc: linux-zigbee-devel, netdev, davem
In-Reply-To: <20111130141827.GA3739@avtobot.cybertron>
Hello colleagues,
On Wed, Nov 30, 2011 at 6:18 PM, Alexander Smirnov
<alex.bluesman.smirnov@gmail.com> wrote:
[skipped]
> This stack has working implementation in 'linux-zigbee.sourceforge.net'
> project, but unfortunately all the development was freezed according to
> unknown issue and it hasn't been merged to mailnline.
>
> Currently I'm the one engineer who continue working on them. So the
> following patch series is based on the project mentioned above, and I just
> cut code into roudimentary pieces with minor fixes.
Alexander, thank you for continuing the work on the project! I'm glad to see
those patches being submitted to the mainline kernel.
> The code in the following patches was tested by 6LowPAN module. I took at230
> transciever driver from 'linux-zigbee' and brought up IPv6 network, it worked.
>
> Could please anyone review patches and let me know what do you think?
Several global notes:
1) Could you please include any (virtual or real) device driver
implementing the stack.
There was a "virtual radio" driver written for SoftMAC devices. The
driver had some small
design problems, but I think the stripped down version can be included
in the patchset.
2) Could you please rearrange the patches a little bit:
I'd really like to see the "monitor" devices interface pushed in the
first round of the patches.
It depends only on "simple mlme" and "RX/TX datapath" patches IIRC. It
would be really
good to merge those things first as it would then allow one to
implement their drivers,
check the radio, capture radio frames, etc.
I'll try reviewing patches really soon (as the time permits). However
could you please specify,
your changes over the last state I pushed to sf.net git repos (devel
or devel-30 branches)
to ease review?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 07/12] [IEEE802154] ieee802154: define simplified mlme interface
From: Dmitry Eremin-Solenikov @ 2011-11-30 16:22 UTC (permalink / raw)
To: Alexander Smirnov; +Cc: linux-zigbee-devel, netdev, davem
In-Reply-To: <1322663126-3987-1-git-send-email-alex.bluesman.smirnov@gmail.com>
On Wed, Nov 30, 2011 at 6:25 PM, Alexander Smirnov
<alex.bluesman.smirnov@gmail.com> wrote:
> Define light-weight mlme interface.
Could you please elaborate, why it is necessary? I created it for the
sub-devices
which didn't have full IEEE 802.15.4 MLME (like monitoring devices,
SMAC or MiWi,
or other proprietary protocols), but I don't see support for those
coming in this patch set.
>
> Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
> ---
> include/net/ieee802154_netdev.h | 11 +++++++++++
> net/ieee802154/nl-mac.c | 2 +-
> 2 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
> index 12a7ee4..5264b00 100644
> --- a/include/net/ieee802154_netdev.h
> +++ b/include/net/ieee802154_netdev.h
> @@ -83,7 +83,12 @@ struct wpan_phy;
> * get_phy should increment the reference counting on returned phy.
> * Use wpan_wpy_put to put that reference.
> */
> +struct simple_mlme_ops {
> + struct wpan_phy *(*get_phy)(const struct net_device *dev);
> +};
> struct ieee802154_mlme_ops {
> + struct simple_mlme_ops wpan_ops;
> +
> int (*assoc_req)(struct net_device *dev,
> struct ieee802154_addr *addr,
> u8 channel, u8 page, u8 cap);
> @@ -112,6 +117,12 @@ struct ieee802154_mlme_ops {
> u8 (*get_bsn)(const struct net_device *dev);
> };
>
> +static inline struct simple_mlme_ops *simple_mlme_ops(
> + const struct net_device *dev)
> +{
> + return dev->ml_priv;
> +}
> +
> static inline struct ieee802154_mlme_ops *ieee802154_mlme_ops(
> const struct net_device *dev)
> {
> diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
> index adaf462..1d23aa6 100644
> --- a/net/ieee802154/nl-mac.c
> +++ b/net/ieee802154/nl-mac.c
> @@ -263,7 +263,7 @@ static int ieee802154_nl_fill_iface(struct sk_buff *msg, u32 pid,
> if (!hdr)
> goto out;
>
> - phy = ieee802154_mlme_ops(dev)->get_phy(dev);
> + phy = simple_mlme_ops(dev)->get_phy(dev);
> BUG_ON(!phy);
>
> NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
> --
> 1.7.2.3
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 1/2] ipv4 : igmp : Delete useless parameter in ip_mc_add1_src()
From: Jun Zhao @ 2011-11-30 16:21 UTC (permalink / raw)
To: davem; +Cc: netdev, Jun Zhao
Need not to used 'delta' flag when add single-source to interface
filter source list.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
net/ipv4/igmp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 22c10b5..e6ed796 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1574,7 +1574,7 @@ out_unlock:
* Add multicast single-source filter to the interface list
*/
static int ip_mc_add1_src(struct ip_mc_list *pmc, int sfmode,
- __be32 *psfsrc, int delta)
+ __be32 *psfsrc)
{
struct ip_sf_list *psf, *psf_prev;
@@ -1709,7 +1709,7 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
pmc->sfcount[sfmode]++;
err = 0;
for (i=0; i<sfcount; i++) {
- err = ip_mc_add1_src(pmc, sfmode, &psfsrc[i], delta);
+ err = ip_mc_add1_src(pmc, sfmode, &psfsrc[i]);
if (err)
break;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/2] ipv6 : mcast : Delete useless parameter in ip6_mc_add1_src()
From: Jun Zhao @ 2011-11-30 16:21 UTC (permalink / raw)
To: davem; +Cc: netdev, Jun Zhao
In-Reply-To: <1322670065-13237-1-git-send-email-mypopydev@gmail.com>
Need not to used 'delta' flag when add single-source to interface
filter source list.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
net/ipv6/mcast.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index ee7839f..933f4c9 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1914,7 +1914,7 @@ static int ip6_mc_del_src(struct inet6_dev *idev, const struct in6_addr *pmca,
* Add multicast single-source filter to the interface list
*/
static int ip6_mc_add1_src(struct ifmcaddr6 *pmc, int sfmode,
- const struct in6_addr *psfsrc, int delta)
+ const struct in6_addr *psfsrc)
{
struct ip6_sf_list *psf, *psf_prev;
@@ -2045,7 +2045,7 @@ static int ip6_mc_add_src(struct inet6_dev *idev, const struct in6_addr *pmca,
pmc->mca_sfcount[sfmode]++;
err = 0;
for (i=0; i<sfcount; i++) {
- err = ip6_mc_add1_src(pmc, sfmode, &psfsrc[i], delta);
+ err = ip6_mc_add1_src(pmc, sfmode, &psfsrc[i]);
if (err)
break;
}
--
1.7.2.5
^ permalink raw reply related
* Re: [MAC802154] DRAFT: IEEE 802.15.4 MAC layer basic implementation
From: Alexander Smirnov @ 2011-11-30 16:54 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Jon Smirl, linux-zigbee-devel, netdev, davem
In-Reply-To: <CALT56yPPXzVH9Mb6LznEyRv42wgGWK_P7Yf8cbWywD4HXtFGTA@mail.gmail.com>
Hello Dmitry,
thank you for the reply,
2011/11/30 Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>:
> Hello colleagues,
>
> On Wed, Nov 30, 2011 at 6:18 PM, Alexander Smirnov
> <alex.bluesman.smirnov@gmail.com> wrote:
>
> [skipped]
>
>> This stack has working implementation in 'linux-zigbee.sourceforge.net'
>> project, but unfortunately all the development was freezed according to
>> unknown issue and it hasn't been merged to mailnline.
>>
>> Currently I'm the one engineer who continue working on them. So the
>> following patch series is based on the project mentioned above, and I just
>> cut code into roudimentary pieces with minor fixes.
>
> Alexander, thank you for continuing the work on the project! I'm glad to see
> those patches being submitted to the mainline kernel.
>
>> The code in the following patches was tested by 6LowPAN module. I took at230
>> transciever driver from 'linux-zigbee' and brought up IPv6 network, it worked.
>>
>> Could please anyone review patches and let me know what do you think?
>
> Several global notes:
>
> 1) Could you please include any (virtual or real) device driver
> implementing the stack.
> There was a "virtual radio" driver written for SoftMAC devices. The
> driver had some small
> design problems, but I think the stripped down version can be included
> in the patchset.
do you think that's a good idea to mix several layers in one patch series?
Won't it be better to push some basic MAC support and only after the drivers?
I see that way a little bit easier for code review.
But if you don't think so, it's not a problem.
>
> 2) Could you please rearrange the patches a little bit:
> I'd really like to see the "monitor" devices interface pushed in the
> first round of the patches.
> It depends only on "simple mlme" and "RX/TX datapath" patches IIRC. It
> would be really
> good to merge those things first as it would then allow one to
> implement their drivers,
> check the radio, capture radio frames, etc.
>
Hmm, sounds good. I agree with this roadmap. :)
> I'll try reviewing patches really soon (as the time permits). However
> could you please specify,
> your changes over the last state I pushed to sf.net git repos (devel
> or devel-30 branches)
> to ease review?
>
The changes are really small and they don't affect the code
structure/logic: using of common style in debug output, rewrite
'fetch_skb' functions, remove several unused lines etc...
> --
> With best wishes
> Dmitry
With best regards,
Alexander
^ permalink raw reply
* Re: ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)
From: Jeroen van Ingen @ 2011-11-30 17:05 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1111300010150.2020@ja.ssi.bg>
Hi Julian,
Thanks for your assistance, it's very much appreciated.
> __ip_dev_find can cause problem if same IP is added on many
> interfaces because it uses hash table implemented with hlist.
> Old versions used only routing lookup and the routing returns
> the first created local route, i.e. the first device where this
> IP was added is returned.
Right, and all ppp interfaces get the same IP as the interface that the
clients use to connect to, which in our case is the "main" IP for the
server.
> And now it is risky to use __ip_dev_find in
> ip_route_output_slow when:
>
> - saddr is provided
> - desired oif is 0
> - daddr is multicast/lbcast
>
> We select oif by ignoring route ordering. May be some
> ppp device wins here because it has this saddr added last but
> is first in hlist.
>
> What is the case after first client is connected, can
> you show output from:
>
> ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
link/ether 00:08:02:91:c9:1f brd ff:ff:ff:ff:ff:ff
inet 130.89.254.233/27 brd 130.89.254.255 scope global eth0
inet 130.89.254.234/27 brd 130.89.254.255 scope global secondary
eth0:1
inet 130.89.254.235/27 brd 130.89.254.255 scope global secondary
eth0:2
inet 130.89.254.236/27 brd 130.89.254.255 scope global secondary
eth0:3
inet6 fe80::208:2ff:fe91:c91f/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq
state UP qlen 1000
link/ether 00:1e:0b:76:83:d6 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21e:bff:fe76:83d6/64 scope link
valid_lft forever preferred_lft forever
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP qlen 100
link/ether 42:a7:29:fa:de:4a brd ff:ff:ff:ff:ff:ff
inet6 fe80::40a7:29ff:fefa:de4a/64 scope link
valid_lft forever preferred_lft forever
5: tap1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP qlen 100
link/ether 3e:1c:6f:5f:a2:a0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3c1c:6fff:fe5f:a2a0/64 scope link
valid_lft forever preferred_lft forever
6: tap2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP qlen 100
link/ether 6a:17:16:92:93:35 brd ff:ff:ff:ff:ff:ff
inet6 fe80::6817:16ff:fe92:9335/64 scope link
valid_lft forever preferred_lft forever
7: tap3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP qlen 100
link/ether ce:99:a3:e6:32:cd brd ff:ff:ff:ff:ff:ff
inet6 fe80::cc99:a3ff:fee6:32cd/64 scope link
valid_lft forever preferred_lft forever
8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP
link/ether 00:1e:0b:76:83:d6 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21e:bff:fe76:83d6/64 scope link
valid_lft forever preferred_lft forever
9: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:1e:0b:76:83:d4 brd ff:ff:ff:ff:ff:ff
10: eth1.183@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue master br0 state UP
link/ether 00:1e:0b:76:83:d6 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21e:bff:fe76:83d6/64 scope link
valid_lft forever preferred_lft forever
11: eth1.184@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP
link/ether 00:1e:0b:76:83:d6 brd ff:ff:ff:ff:ff:ff
inet 130.89.96.8/21 brd 130.89.103.255 scope global eth1.184
inet6 fe80::21e:bff:fe76:83d6/64 scope link
valid_lft forever preferred_lft forever
14: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc
pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 130.89.254.233 peer 130.89.100.119/32 scope global ppp0
> ip route list table local
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src
127.0.0.1
broadcast 130.89.96.0 dev eth1.184 proto kernel scope link src
130.89.96.8
local 130.89.96.8 dev eth1.184 proto kernel scope host src
130.89.96.8
broadcast 130.89.103.255 dev eth1.184 proto kernel scope link src
130.89.96.8
broadcast 130.89.254.224 dev eth0 proto kernel scope link src
130.89.254.233
local 130.89.254.233 dev eth0 proto kernel scope host src
130.89.254.233
local 130.89.254.233 dev ppp0 proto kernel scope host src
130.89.254.233
local 130.89.254.234 dev eth0 proto kernel scope host src
130.89.254.233
local 130.89.254.235 dev eth0 proto kernel scope host src
130.89.254.233
local 130.89.254.236 dev eth0 proto kernel scope host src
130.89.254.233
broadcast 130.89.254.255 dev eth0 proto kernel scope link src
130.89.254.233
> If the above is true may be we have to find a
> way to return the first device where the IP is added.
> May be this is the main rule that is used when one adds
> same IP on many interfaces.
>
> May be the solution is to convert inet_addr_lst
> from hlist to normal list, so that we can append new
> addresses at tail and __ip_dev_find to find the first
> device where IP was added.
Perhaps the solution in our case is indeed to have all PPTP clients
connect to a secondary IP on the server; then all PPP interfaces still
share the same address, but it probably won't be the address that our
server selects as source for broadcast traffic (DHCP or otherwise). We
already have a couple of secondaries on the interface in question (as
you can see in "ip addr show"). We'll try this tomorrow, it's also in
line with your later suggestion in reply to David.
Another workaround for us might be to tell Radius to use a different
source IP for the DHCP address allocation when a client connects. Just
tested with a second client, this seems to work.
I'll let you know the results tomorrow.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
^ 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