* [PATCH 09/10] nl802154: support START-CONFIRM primitive
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-9-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/nl802154.h | 9 +++++++++
net/ieee802154/netlink.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 6096096..e554ecd 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -114,4 +114,13 @@ int ieee802154_nl_scan_confirm(struct net_device *dev,
int ieee802154_nl_beacon_indic(struct net_device *dev, u16 panid,
u16 coord_addr);
+/**
+ * ieee802154_nl_start_confirm - Notify userland of completion of start.
+ * @dev: The device which was instructed to scan.
+ * @status: The status of the scan operation.
+ *
+ * Note: This is in section 7.1.14 of the IEEE 802.15.4 document.
+ */
+int ieee802154_nl_start_confirm(struct net_device *dev, u8 status);
+
#endif
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index 6fc6d6f..70a067e 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -31,6 +31,7 @@
#include <linux/nl802154.h>
#include <net/af_ieee802154.h>
#include <net/nl802154.h>
+#include <net/ieee802154.h>
#include <net/ieee802154_netdev.h>
static unsigned int ieee802154_seq_num;
@@ -262,6 +263,31 @@ nla_put_failure:
}
EXPORT_SYMBOL(ieee802154_nl_scan_confirm);
+int ieee802154_nl_start_confirm(struct net_device *dev, u8 status)
+{
+ struct sk_buff *msg;
+
+ pr_debug("%s\n", __func__);
+
+ msg = ieee802154_nl_create(0, IEEE802154_START_CONF);
+ if (!msg)
+ return -ENOBUFS;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U32(msg, IEEE802154_ATTR_DEV_INDEX, dev->ifindex);
+ NLA_PUT(msg, IEEE802154_ATTR_HW_ADDR, IEEE802154_ADDR_LEN,
+ dev->dev_addr);
+
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, status);
+
+ return ieee802154_nl_finish(msg);
+
+nla_put_failure:
+ nlmsg_free(msg);
+ return -ENOBUFS;
+}
+EXPORT_SYMBOL(ieee802154_nl_start_confirm);
+
static int ieee802154_nl_fill_iface(struct sk_buff *msg, u32 pid,
u32 seq, int flags, struct net_device *dev)
{
@@ -462,6 +488,12 @@ static int ieee802154_start_req(struct sk_buff *skb, struct genl_info *info)
blx = nla_get_u8(info->attrs[IEEE802154_ATTR_BAT_EXT]);
coord_realign = nla_get_u8(info->attrs[IEEE802154_ATTR_COORD_REALIGN]);
+ if (addr.short_addr == IEEE802154_ADDR_BROADCAST) {
+ ieee802154_nl_start_confirm(dev, IEEE802154_NO_SHORT_ADDRESS);
+ dev_put(dev);
+ return -EINVAL;
+ }
+
ret = ieee802154_mlme_ops(dev)->start_req(dev, &addr, channel,
bcn_ord, sf_ord, pan_coord, blx, coord_realign);
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 08/10] af_ieee802154: add support for WANT_ACK socket option
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-8-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/af_ieee802154.h | 5 +++
net/ieee802154/dgram.c | 58 ++++++++++++++++++++++++++++++++++++++++---
2 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/include/net/af_ieee802154.h b/include/net/af_ieee802154.h
index e9c70ea..75e64c7 100644
--- a/include/net/af_ieee802154.h
+++ b/include/net/af_ieee802154.h
@@ -54,4 +54,9 @@ struct sockaddr_ieee802154 {
struct ieee802154_addr addr;
};
+/* get/setsockopt */
+#define SOL_IEEE802154 0
+
+#define WPAN_WANTACK 0
+
#endif
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 25018a9..77ae685 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -44,6 +44,7 @@ struct dgram_sock {
struct ieee802154_addr dst_addr;
unsigned bound:1;
+ unsigned want_ack:1;
};
static inline struct dgram_sock *dgram_sk(const struct sock *sk)
@@ -51,7 +52,6 @@ static inline struct dgram_sock *dgram_sk(const struct sock *sk)
return container_of(sk, struct dgram_sock, sk);
}
-
static void dgram_hash(struct sock *sk)
{
write_lock_bh(&dgram_lock);
@@ -74,6 +74,7 @@ static int dgram_init(struct sock *sk)
ro->dst_addr.addr_type = IEEE802154_ADDR_LONG;
ro->dst_addr.pan_id = 0xffff;
+ ro->want_ack = 1;
memset(&ro->dst_addr.hwaddr, 0xff, sizeof(ro->dst_addr.hwaddr));
return 0;
}
@@ -237,7 +238,10 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
skb_reset_network_header(skb);
- mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA | MAC_CB_FLAG_ACKREQ;
+ mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ if (ro->want_ack)
+ mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+
mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
err = dev_hard_header(skb, dev, ETH_P_IEEE802154, &ro->dst_addr,
ro->bound ? &ro->src_addr : NULL, size);
@@ -382,13 +386,59 @@ int ieee802154_dgram_deliver(struct net_device *dev, struct sk_buff *skb)
static int dgram_getsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user *optlen)
{
- return -EOPNOTSUPP;
+ struct dgram_sock *ro = dgram_sk(sk);
+
+ int val, len;
+
+ if (level != SOL_IEEE802154)
+ return -EOPNOTSUPP;
+
+ if (get_user(len, optlen))
+ return -EFAULT;
+
+ len = min_t(unsigned int, len, sizeof(int));
+
+ switch (optname) {
+ case WPAN_WANTACK:
+ val = ro->want_ack;
+ break;
+ default:
+ return -ENOPROTOOPT;
+ }
+
+ if (put_user(len, optlen))
+ return -EFAULT;
+ if (copy_to_user(optval, &val, len))
+ return -EFAULT;
+ return 0;
}
static int dgram_setsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user optlen)
{
- return -EOPNOTSUPP;
+ struct dgram_sock *ro = dgram_sk(sk);
+ int val;
+ int err = 0;
+
+ if (optlen < sizeof(int))
+ return -EINVAL;
+
+ if (get_user(val, (int __user *)optval))
+ return -EFAULT;
+
+ lock_sock(sk);
+
+ switch (optname) {
+ case WPAN_WANTACK:
+ ro->want_ack = !!val;
+ break;
+ default:
+ err = -ENOPROTOOPT;
+ break;
+ }
+
+ release_sock(sk);
+ return err;
}
struct proto ieee802154_dgram_prot = {
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 07/10] af_ieee802154: minor cleanup in dgram_bind
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-7-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1) fix ro->bound protection by socket lock
2) make ro->bound bit instead of int
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/dgram.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index d1da6c6..25018a9 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -40,9 +40,10 @@ static DEFINE_RWLOCK(dgram_lock);
struct dgram_sock {
struct sock sk;
- int bound;
struct ieee802154_addr src_addr;
struct ieee802154_addr dst_addr;
+
+ unsigned bound:1;
};
static inline struct dgram_sock *dgram_sk(const struct sock *sk)
@@ -86,18 +87,18 @@ static int dgram_bind(struct sock *sk, struct sockaddr *uaddr, int len)
{
struct sockaddr_ieee802154 *addr = (struct sockaddr_ieee802154 *)uaddr;
struct dgram_sock *ro = dgram_sk(sk);
- int err = 0;
+ int err = -EINVAL;
struct net_device *dev;
+ lock_sock(sk);
+
ro->bound = 0;
if (len < sizeof(*addr))
- return -EINVAL;
+ goto out;
if (addr->family != AF_IEEE802154)
- return -EINVAL;
-
- lock_sock(sk);
+ goto out;
dev = ieee802154_get_dev(sock_net(sk), &addr->addr);
if (!dev) {
@@ -113,6 +114,7 @@ static int dgram_bind(struct sock *sk, struct sockaddr *uaddr, int len)
memcpy(&ro->src_addr, &addr->addr, sizeof(struct ieee802154_addr));
ro->bound = 1;
+ err = 0;
out_put:
dev_put(dev);
out:
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 06/10] af_ieee802154: provide dummy get/setsockopt
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-6-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Provide dummt get/setsockopt implementations to stop these
syscalls from oopsing on our sockets.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/dgram.c | 14 ++++++++++++++
net/ieee802154/raw.c | 14 ++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 53dd912..d1da6c6 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -377,6 +377,18 @@ int ieee802154_dgram_deliver(struct net_device *dev, struct sk_buff *skb)
return ret;
}
+static int dgram_getsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user *optlen)
+{
+ return -EOPNOTSUPP;
+}
+
+static int dgram_setsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user optlen)
+{
+ return -EOPNOTSUPP;
+}
+
struct proto ieee802154_dgram_prot = {
.name = "IEEE-802.15.4-MAC",
.owner = THIS_MODULE,
@@ -391,5 +403,7 @@ struct proto ieee802154_dgram_prot = {
.connect = dgram_connect,
.disconnect = dgram_disconnect,
.ioctl = dgram_ioctl,
+ .getsockopt = dgram_getsockopt,
+ .setsockopt = dgram_setsockopt,
};
diff --git a/net/ieee802154/raw.c b/net/ieee802154/raw.c
index ea8d1f1..60dee69 100644
--- a/net/ieee802154/raw.c
+++ b/net/ieee802154/raw.c
@@ -238,6 +238,18 @@ void ieee802154_raw_deliver(struct net_device *dev, struct sk_buff *skb)
read_unlock(&raw_lock);
}
+static int raw_getsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user *optlen)
+{
+ return -EOPNOTSUPP;
+}
+
+static int raw_setsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user optlen)
+{
+ return -EOPNOTSUPP;
+}
+
struct proto ieee802154_raw_prot = {
.name = "IEEE-802.15.4-RAW",
.owner = THIS_MODULE,
@@ -250,5 +262,7 @@ struct proto ieee802154_raw_prot = {
.unhash = raw_unhash,
.connect = raw_connect,
.disconnect = raw_disconnect,
+ .getsockopt = raw_getsockopt,
+ .setsockopt = raw_setsockopt,
};
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 05/10] nl802154: add support for dumping WPAN interface information
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-5-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/linux/nl802154.h | 2 +
net/ieee802154/netlink.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index 266dd96..9a1af5f 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -111,6 +111,8 @@ enum {
IEEE802154_RX_ENABLE_REQ, /* Not supported yet */
IEEE802154_RX_ENABLE_CONF, /* Not supported yet */
+ IEEE802154_LIST_IFACE,
+
__IEEE802154_CMD_MAX,
};
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index a615b9d..6fc6d6f 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -19,6 +19,7 @@
* Written by:
* Sergey Lapin <slapin-9cOl001CZnBAfugRpC6u6w@public.gmane.org>
* Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ * Maxim Osipov <maxim.osipov-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>
*/
#include <linux/kernel.h>
@@ -26,6 +27,7 @@
#include <linux/netdevice.h>
#include <net/netlink.h>
#include <net/genetlink.h>
+#include <net/sock.h>
#include <linux/nl802154.h>
#include <net/af_ieee802154.h>
#include <net/nl802154.h>
@@ -73,7 +75,7 @@ static int ieee802154_nl_finish(struct sk_buff *msg)
/* XXX: nlh is right at the start of msg */
void *hdr = genlmsg_data(NLMSG_DATA(msg->data));
- if (!genlmsg_end(msg, hdr))
+ if (genlmsg_end(msg, hdr) < 0)
goto out;
return genlmsg_multicast(msg, 0, ieee802154_coord_mcgrp.id,
@@ -260,6 +262,35 @@ nla_put_failure:
}
EXPORT_SYMBOL(ieee802154_nl_scan_confirm);
+static int ieee802154_nl_fill_iface(struct sk_buff *msg, u32 pid,
+ u32 seq, int flags, struct net_device *dev)
+{
+ void *hdr;
+
+ pr_debug("%s\n", __func__);
+
+ hdr = genlmsg_put(msg, 0, seq, &ieee802154_coordinator_family, flags,
+ IEEE802154_LIST_IFACE);
+ if (!hdr)
+ goto out;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U32(msg, IEEE802154_ATTR_DEV_INDEX, dev->ifindex);
+
+ NLA_PUT(msg, IEEE802154_ATTR_HW_ADDR, IEEE802154_ADDR_LEN,
+ dev->dev_addr);
+ NLA_PUT_U16(msg, IEEE802154_ATTR_SHORT_ADDR,
+ ieee802154_mlme_ops(dev)->get_short_addr(dev));
+ NLA_PUT_U16(msg, IEEE802154_ATTR_PAN_ID,
+ ieee802154_mlme_ops(dev)->get_pan_id(dev));
+ return genlmsg_end(msg, hdr);
+
+nla_put_failure:
+ genlmsg_cancel(msg, hdr);
+out:
+ return -EMSGSIZE;
+}
+
/* Requests from userspace */
static struct net_device *ieee802154_nl_get_dev(struct genl_info *info)
{
@@ -272,7 +303,7 @@ static struct net_device *ieee802154_nl_get_dev(struct genl_info *info)
dev = dev_get_by_name(&init_net, name);
} else if (info->attrs[IEEE802154_ATTR_DEV_INDEX])
dev = dev_get_by_index(&init_net,
- nla_get_u32(info->attrs[IEEE802154_ATTR_DEV_INDEX]));
+ nla_get_u32(info->attrs[IEEE802154_ATTR_DEV_INDEX]));
else
return NULL;
@@ -466,6 +497,67 @@ static int ieee802154_scan_req(struct sk_buff *skb, struct genl_info *info)
return ret;
}
+static int ieee802154_list_iface(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ /* Request for interface name, index, type, IEEE address,
+ PAN Id, short address */
+ struct sk_buff *msg;
+ struct net_device *dev = NULL;
+ int rc = -ENOBUFS;
+
+ pr_debug("%s\n", __func__);
+
+ dev = ieee802154_nl_get_dev(info);
+ if (!dev)
+ return -ENODEV;
+
+ msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+ if (!msg)
+ goto out_dev;
+
+ rc = ieee802154_nl_fill_iface(msg, info->snd_pid, info->snd_seq,
+ 0, dev);
+ if (rc < 0)
+ goto out_free;
+
+ dev_put(dev);
+
+ return genlmsg_unicast(msg, info->snd_pid);
+out_free:
+ nlmsg_free(msg);
+out_dev:
+ dev_put(dev);
+ return rc;
+
+}
+
+static int ieee802154_dump_iface(struct sk_buff *skb,
+ struct netlink_callback *cb)
+{
+ struct net *net = sock_net(skb->sk);
+ struct net_device *dev;
+ int idx;
+ int s_idx = cb->args[0];
+
+ pr_debug("%s\n", __func__);
+
+ idx = 0;
+ for_each_netdev(net, dev) {
+ if (idx < s_idx || (dev->type != ARPHRD_IEEE802154))
+ goto cont;
+
+ if (ieee802154_nl_fill_iface(skb, NETLINK_CB(cb->skb).pid,
+ cb->nlh->nlmsg_seq, NLM_F_MULTI, dev) < 0)
+ break;
+cont:
+ idx++;
+ }
+ cb->args[0] = idx;
+
+ return skb->len;
+}
+
#define IEEE802154_OP(_cmd, _func) \
{ \
.cmd = _cmd, \
@@ -475,12 +567,22 @@ static int ieee802154_scan_req(struct sk_buff *skb, struct genl_info *info)
.flags = GENL_ADMIN_PERM, \
}
+#define IEEE802154_DUMP(_cmd, _func, _dump) \
+ { \
+ .cmd = _cmd, \
+ .policy = ieee802154_policy, \
+ .doit = _func, \
+ .dumpit = _dump, \
+ }
+
static struct genl_ops ieee802154_coordinator_ops[] = {
IEEE802154_OP(IEEE802154_ASSOCIATE_REQ, ieee802154_associate_req),
IEEE802154_OP(IEEE802154_ASSOCIATE_RESP, ieee802154_associate_resp),
IEEE802154_OP(IEEE802154_DISASSOCIATE_REQ, ieee802154_disassociate_req),
IEEE802154_OP(IEEE802154_SCAN_REQ, ieee802154_scan_req),
IEEE802154_OP(IEEE802154_START_REQ, ieee802154_start_req),
+ IEEE802154_DUMP(IEEE802154_LIST_IFACE, ieee802154_list_iface,
+ ieee802154_dump_iface),
};
static int __init ieee802154_nl_init(void)
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Paul Moore @ 2009-08-07 12:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: Eric W. Biederman, netdev, David Miller
In-Reply-To: <20090807000021.GA1566@gondor.apana.org.au>
On Thursday 06 August 2009 08:00:21 pm Herbert Xu wrote:
> On Thu, Aug 06, 2009 at 02:20:20PM -0400, Paul Moore wrote:
> > The code currently looks something like this:
> >
> > err = -ENOMEM;
> > buf = alloc(...);
> > if (!buf)
> > goto label;
> >
> > This means that in the common case where 'alloc()' completes without
> > error we are doing an extra, unnecessary assignment where we set the
> > value in 'err'. Now, if we change this slightly to match what I proposed
> > in the patch:
> >
> > buf = alloc(...);
> > if (!buf) {
> > err = -ENOMEM;
> > goto label;
> > }
> >
> > We eliminate that extra assignment in the case where 'alloc()' completes
> > without error, which should result in more efficient code (less
> > instructions in the common case). Am I wrong? If that is the case I
> > would appreciate an explanation ...
>
> Your style potentially introduces a second jump which may end
> up being worse compared to the extra work on a modern CPU.
Thanks, I hadn't thought of that possibility. I suppose the impact of a
second jump is going to depend quite a bit on the hardware it runs on
(pipeline depth, branch prediction, etc.) and isn't as easy to quantify as I
had hoped. Oh well, I appreciate the explanation anyway :)
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less restrictive
From: Rémi Denis-Courmont @ 2009-08-07 11:54 UTC (permalink / raw)
To: ext Oliver Hartkopp
Cc: netdev@vger.kernel.org, socketcan-users@lists.berlios.de
In-Reply-To: <4A7C117E.5010005@hartkopp.net>
On Friday 07 August 2009 14:35:26 ext Oliver Hartkopp wrote:
> So you would need to have an originating interface with ARPHRD_CAN ...
>
> Do you think, it's still possible with the TUN driver?
Hmm, actually no... TUN can create packets with any type (ETH_P_*), but
devices always have ARPHRD_NONE type.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* [PATCH] fec: fix FEC driver packet transmission breakage
From: Greg Ungerer @ 2009-08-07 3:58 UTC (permalink / raw)
To: netdev; +Cc: gerg, s.hauer
fec: fix FEC driver packet transmission breakage
Commit f0b3fbeae11a526c3d308b691684589ee37c359b breaks transmission of
packets where the skb data buffer is not memory aligned according to
FEC_ALIGNMENT. It incorrectly passes to dma_sync_single() the buffer
address directly from the skb, instead of the address calculated for
use (which may be the skb address or one of the bounce buffers).
It seems there is no use converting the cpu address of the buffer to
a physical either, since dma_map_single() expects the cpu address and
will return the dma address to use in the descriptor. So remove the use
of __pa() on the buffer address as well.
This patch is against 2.6.30-rc5. This breakage is a regression over
2.6.30, which does not have this problem.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 0d2ab43..a32230b 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -285,6 +285,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fec_enet_private *fep = netdev_priv(dev);
struct bufdesc *bdp;
+ void *bufaddr;
unsigned short status;
unsigned long flags;
@@ -312,7 +313,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
status &= ~BD_ENET_TX_STATS;
/* Set buffer length and buffer pointer */
- bdp->cbd_bufaddr = __pa(skb->data);
+ bufaddr = skb->data;
bdp->cbd_datlen = skb->len;
/*
@@ -320,11 +321,11 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
* 4-byte boundaries. Use bounce buffers to copy data
* and get it aligned. Ugh.
*/
- if (bdp->cbd_bufaddr & FEC_ALIGNMENT) {
+ if (((unsigned long) bufaddr) & FEC_ALIGNMENT) {
unsigned int index;
index = bdp - fep->tx_bd_base;
memcpy(fep->tx_bounce[index], (void *)skb->data, skb->len);
- bdp->cbd_bufaddr = __pa(fep->tx_bounce[index]);
+ bufaddr = fep->tx_bounce[index];
}
/* Save skb pointer */
@@ -336,7 +337,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Push the data cache so the CPM does not get stale memory
* data.
*/
- bdp->cbd_bufaddr = dma_map_single(&dev->dev, skb->data,
+ bdp->cbd_bufaddr = dma_map_single(&dev->dev, bufaddr,
FEC_ENET_TX_FRSIZE, DMA_TO_DEVICE);
/* Send it on its way. Tell FEC it's ready, interrupt when done,
^ permalink raw reply related
* Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less restrictive
From: Luotao Fu @ 2009-08-07 11:46 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: R?mi Denis-Courmont, Luotao Fu, netdev@vger.kernel.org,
socketcan-users@lists.berlios.de, Michael Olbrich
In-Reply-To: <4A7C117E.5010005@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
Hi Oliver,
On Fri, Aug 07, 2009 at 01:35:26PM +0200, Oliver Hartkopp wrote:
> R?mi Denis-Courmont wrote:
....
>
> @Luotao: I talked to Urs and we discussed to prepare a patch that only creates
> a warning and drops the skb afterwards, as the problem is not critical for a
> proper ongoing kernel operation. I think, that was you original intention:
>
> if (!net_eq(dev_net(dev), &init_net) ||
> WARN_ON(dev->type != ARPHRD_CAN) ||
> WARN_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8)) {
> kfree_skb(skb);
> return NET_RX_BAD;
> }
>
> Would this be ok for you?
I'm absolutely fine with this.
thx
cheers
Fu
--
Pengutronix e.K. | Dipl.-Ing. Luotao Fu |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less restrictive
From: Oliver Hartkopp @ 2009-08-07 11:35 UTC (permalink / raw)
To: Rémi Denis-Courmont, Luotao Fu
Cc: netdev@vger.kernel.org, socketcan-users@lists.berlios.de,
Michael Olbrich
In-Reply-To: <200908070952.56922.remi.denis-courmont@nokia.com>
Rémi Denis-Courmont wrote:
> Moving to netdev....
>
> On Thursday 06 August 2009 19:48:23 ext Oliver Hartkopp wrote:
>> The CAN applications can rely on getting proper CAN frames with this check.
>> It was introduced some time ago together with several other sanity checks -
>> even on the TX path.
>>
>> The CAN core *only* consumes skbuffs originated from a CAN netdevice
>> (ARPHRD_CAN).
>>
>> When this BUG() triggers, someone provided a definitely broken *CAN*
>> network driver, and this needs to be fixed on that level. It is really not
>> that problematic to ensure proper CAN frames on driver level ... this
>> sanity check should not be needed to be performed by every single
>> application.
>
> AFAIK, the TUN driver can inject layer-2 frames of any type, any size and any
> content from userspace into the packet type handler. Sure enough, you need
> CAP_NET_ADMIN and r/w access to /dev/net/tun but is it sufficient to bring the
> system down?
>
The complete code section currently looks like this:
static int can_rcv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *pt, struct net_device *orig_dev)
{
struct dev_rcv_lists *d;
struct can_frame *cf = (struct can_frame *)skb->data;
int matches;
if (dev->type != ARPHRD_CAN || !net_eq(dev_net(dev), &init_net)) {
kfree_skb(skb);
return 0;
}
BUG_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
(..)
So you would need to have an originating interface with ARPHRD_CAN ...
Do you think, it's still possible with the TUN driver?
@Luotao: I talked to Urs and we discussed to prepare a patch that only creates
a warning and drops the skb afterwards, as the problem is not critical for a
proper ongoing kernel operation. I think, that was you original intention:
if (!net_eq(dev_net(dev), &init_net) ||
WARN_ON(dev->type != ARPHRD_CAN) ||
WARN_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8)) {
kfree_skb(skb);
return NET_RX_BAD;
}
Would this be ok for you?
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH][RFC] net/bridge: add basic VEPA support
From: Arnd Bergmann @ 2009-08-07 11:29 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Fischer, Anna, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org, evb@yahoogroups.com,
davem@davemloft.net, kaber@trash.net, adobriyan@gmail.com,
Paul Congdon (UC Davis), Or Gerlitz
In-Reply-To: <20090806210002.75beb7c6@nehalam>
On Friday 07 August 2009, Stephen Hemminger wrote:
> So instead of adding more stuff to existing bridge code, why not
> have a new driver for just VEPA. You could
> do it with a simple version of macvlan type driver.
The current macvlan driver already does the downstream side of
VEPA and only needs a connection to KVM et al, either using
Or's qemu packet socket interface, or using the macvtap driver
I posted.
Now Anna's patch also addresses the upstream side of VEPA, by
making it possible for the bridge code to send frames back
in the bridge code that they were received from, if that port
is marked as a hairpin mode port.
Is your suggestion to do that part also with a macvlan type driver?
I've thought about this before, and I guess that would mean
basically the same as the macvlan driver, except hashing the
source MAC address instead of the destination MAC address for
inbound frames. That way you should be able to do something
like:
Host A Host B
/- nalvcam0 -\ /- macvlan0 - 192.168.1.1
br0 -| |- ethA === ethB -|
\- nalvcam1 -/ \- macvlan1 - 192.168.1.2
Now assuming that macvlan0 and macvlan1 are in different
network namespaces or belong to different KVM guests, these
guests would be able to communicate with each other through
the bridge on host A, which can set the policy (using ebtables)
for this communication and get interface statistics on its
nalvcam interfaces. Also, instead of having the br0, Host A could
assign an IP addresses to the two nalvcam interfaces that host
B has, and use IP forwarding between the guests of host B.
Arnd <><
^ permalink raw reply
* Re: 3x59x-fix-pci-resource-management.patch
From: Sergei Shtylyov @ 2009-08-07 10:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Steffen Klassert, netdev
In-Reply-To: <20090806154223.b9b9759e.akpm@linux-foundation.org>
Hello.
Andrew Morton wrote:
> Guys, I seem to have been sitting on the below patch for, err, three years.
> I generally do this because there's some issue which needs to be
> addressed, but the patch didn't address it right.
In this case it was different: you just wanted the patch to be verifed
on an EISA card...
On Mon, 14 Aug 2006 14:31:46 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:
>> ACK, shall I apply this to netdev#upstream ?
Spose so, but let's not go mainline until I've had a chance to test an
EISA card and a cardbus card.
There was several more comments from you but they all got resolved
between you and Jeff at the time...
> Can we please have a revisit and work out what we should do with this?
> Thanks.
WBR, Sergei
^ permalink raw reply
* Forgot "[PATCH]" - Re: Use correct NET_RX_* returns for atalk_rcv()
From: Mark Smith @ 2009-08-07 10:34 UTC (permalink / raw)
To: Mark Smith; +Cc: acme, netdev
In-Reply-To: <20090807185122.30f022de.lk-netdev@lk-netdev.nosense.org>
On Fri, 7 Aug 2009 18:51:22 +0930
Mark Smith <lk-netdev@lk-netdev.nosense.org> wrote:
>
> In all rx'd SKB cases, atalk_rcv() either eventually jumps to or falls through
> to the label out:, which returns numeric 0. Numeric 0 corresponds to
> NET_RX_SUCCESS, which is incorrect in failed SKB cases.
<snip>
^ permalink raw reply
* Re: some bug in iproute2
From: Jarek Poplawski @ 2009-08-07 10:12 UTC (permalink / raw)
To: Sergey Popov; +Cc: netdev, jamal
In-Reply-To: <20090806115035.42a22dfc@azure>
On 06-08-2009 10:50, Sergey Popov wrote:
> # tc f add dev eth0 parent 1: proto ip prio 2 u32 match u32 0 0 action ipt -j MARK --set-mark 1
> /usr/lib64/iptables/libipt_mark.so: cannot open shared object file: No such file or directory
> failed to find target MARK
>
> bad action parsing
> parse_action: bad value (5:ipt)!
> Illegal "action"
>
>
> But mark target is compiled in kernel (not a module)
>
> # iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-mark 1
> # iptables -t mangle -L PREROUTING
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
> MARK all -- anywhere anywhere MARK xset
> 0x1/0xffffffff
>
> This shouldn't be.
If you're using iptables > 1.4.2 then it's a known problem.
You can read more in a netdev thread:
Subject: iproute2 action/policer question
starting date: Tue, 09 Jun 2009 22:10:46 +0200
Jarek P.
^ permalink raw reply
* Re: 3x59x-fix-pci-resource-management.patch
From: Steffen Klassert @ 2009-08-07 10:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Sergei Shtylyov, netdev
In-Reply-To: <20090806154223.b9b9759e.akpm@linux-foundation.org>
On Thu, Aug 06, 2009 at 03:42:23PM -0700, Andrew Morton wrote:
> /* PCI-only startup logic */
> if (pdev) {
> - /* EISA resources already marked, so only PCI needs to do this here */
> - /* Ignore return value, because Cardbus drivers already allocate for us */
> - if (request_region(dev->base_addr, vci->io_size, print_name) != NULL)
> - vp->must_free_region = 1;
> -
I don't know what cardbus does, but __request_region() returns NULL on
memory allocation failure for struct resource too. So this did not work
in all cases anyway. If cardbus allocates for us, we should handle it in
some way, if not I'm fine with the patch as it is.
^ permalink raw reply
* [PATCH] e1000e: fix use of pci_enable_pcie_error_reporting
From: Xiaotian Feng @ 2009-08-07 9:36 UTC (permalink / raw)
To: john.ronciak, peter.p.waskiewicz.jr, bruce.w.allan,
jesse.brandeburg, jeffrey.t.kirsher, davem
Cc: e1000-devel, netdev, linux-kernel, Xiaotian Feng
commit 111b9dc5 introduces pcie aer support for e1000e, but it is not
reasonable to disable it in e1000_remove but enable it in e1000_resume.
This patch enables aer support in e1000_probe.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
---
drivers/net/e1000e/netdev.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 63415bb..e2f0304 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4670,14 +4670,6 @@ static int e1000_resume(struct pci_dev *pdev)
return err;
}
- /* AER (Advanced Error Reporting) hooks */
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
-
pci_set_master(pdev);
pci_enable_wake(pdev, PCI_D3hot, 0);
@@ -4990,6 +4982,14 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
if (err)
goto err_pci_reg;
+ /* AER (Advanced Error Reporting) hooks */
+ err = pci_enable_pcie_error_reporting(pdev);
+ if (err) {
+ dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
+ "0x%x\n", err);
+ /* non-fatal, continue */
+ }
+
pci_set_master(pdev);
/* PCI config space info */
err = pci_save_state(pdev);
--
1.6.2.5
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* Use correct NET_RX_* returns for atalk_rcv()
From: Mark Smith @ 2009-08-07 9:21 UTC (permalink / raw)
To: acme; +Cc: netdev
In all rx'd SKB cases, atalk_rcv() either eventually jumps to or falls through
to the label out:, which returns numeric 0. Numeric 0 corresponds to
NET_RX_SUCCESS, which is incorrect in failed SKB cases.
This patch makes atalk_rcv() provide the correct returns by:
o explicitly returning NET_RX_SUCCESS in the two success cases
o having the out: label return NET_RX_DROP, instead of numeric 0
o making the failed SKB labels and processing more consistent with other
_rcv() routines in the kernel, simplifying validation and removing a
backwards goto
Signed-off-by: Mark Smith <markzzzsmith@yahoo.com.au>
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index 590b839..2377ebe 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1398,7 +1398,7 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev,
__u16 len_hops;
if (!net_eq(dev_net(dev), &init_net))
- goto freeit;
+ goto drop;
/* Don't mangle buffer if shared */
if (!(skb = skb_share_check(skb, GFP_ATOMIC)))
@@ -1406,7 +1406,7 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev,
/* Size check and make sure header is contiguous */
if (!pskb_may_pull(skb, sizeof(*ddp)))
- goto freeit;
+ goto drop;
ddp = ddp_hdr(skb);
@@ -1424,7 +1424,7 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev,
if (skb->len < sizeof(*ddp) || skb->len < (len_hops & 1023)) {
pr_debug("AppleTalk: dropping corrupted frame (deh_len=%u, "
"skb->len=%u)\n", len_hops & 1023, skb->len);
- goto freeit;
+ goto drop;
}
/*
@@ -1434,7 +1434,7 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev,
if (ddp->deh_sum &&
atalk_checksum(skb, len_hops & 1023) != ddp->deh_sum)
/* Not a valid AppleTalk frame - dustbin time */
- goto freeit;
+ goto drop;
/* Check the packet is aimed at us */
if (!ddp->deh_dnet) /* Net 0 is 'this network' */
@@ -1447,7 +1447,7 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev,
* AppleTalk iface
*/
atalk_route_packet(skb, dev, ddp, len_hops, origlen);
- goto out;
+ return NET_RX_SUCCESS;
}
/* if IP over DDP is not selected this code will be optimized out */
@@ -1463,18 +1463,21 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev,
sock = atalk_search_socket(&tosat, atif);
if (!sock) /* But not one of our sockets */
- goto freeit;
+ goto drop;
/* Queue packet (standard) */
skb->sk = sock;
if (sock_queue_rcv_skb(sock, skb) < 0)
- goto freeit;
-out:
- return 0;
-freeit:
+ goto drop;
+
+ return NET_RX_SUCCESS;
+
+drop:
kfree_skb(skb);
- goto out;
+out:
+ return NET_RX_DROP;
+
}
/*
^ permalink raw reply related
* Re: [PATCH] be2net: Implementation of request_firmware interface.
From: Ram Pai @ 2009-08-07 9:20 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Sarveshwar Bandi, netdev, davem
In-Reply-To: <1246803604.3898.6.camel@deadeye>
On Sun, 2009-07-05 at 15:20 +0100, Ben Hutchings wrote:
> On Sun, 2009-07-05 at 17:46 +0530, Sarveshwar Bandi wrote:
> > I understand that most drivers use request_firmware() to load volatile
> > firmware. I do see that there are other nic drivers that use this inferface to
> > flash persistent firmware.
> >
> > We have other tools for offline flashing; but there is requirement
> > to flash f/w through driver without having to use other proprietary tools.
>
> The firmware blob is proprietary and has to be distributed separately
> from the kernel. So does it really matter that you have to distribute a
> special tool as well?
>
> (Based on requirements specified by major OEMs, I have implemented
> firmware update through the sfc driver (MDIO and MTD interfaces) but
> under the control of a separate tool.)
>
> > Since the firmware load happens only when there is a version mismatch with
> > f/w in /lib/firmware, Users who want to avoid automatic flashing at boot time
> > can choose not to copy the f/w file under /lib/firmware.
> [...]
>
> Is there a way of loading the firmware into the controller's RAM but not
> writing it to flash? That ought to be the default behaviour.
>
Given that the volatile and non-volatile firmware reside in the same
file, it is not possible for the driver to selectively load the intended
firmware.
However, is this behavior a gating factor for this patch from being
accepted?
RP
> Ben.
>
--
Ram Pai
System X Device-Driver Enablement Lead
Linux Technology Center
Beaverton OR-97006
503-5783752 t/l 7753752
linuxram@us.ibm.com
^ permalink raw reply
* Re: 3x59x-fix-pci-resource-management.patch
From: Andrew Morton @ 2009-08-07 8:33 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Sergei Shtylyov, netdev
In-Reply-To: <20090807081928.GA12932@skl-net.de>
On Fri, 7 Aug 2009 10:19:28 +0200 Steffen Klassert <klassert@mathematik.tu-chemnitz.de> wrote:
> On Thu, Aug 06, 2009 at 03:42:23PM -0700, Andrew Morton wrote:
> >
> > Guys, I seem to have been sitting on the below patch for, err, three years.
> >
> > I generally do this because there's some issue which needs to be
> > addressed, but the patch didn't address it right.
> >
> > Can we please have a revisit and work out what we should do with this?
> >
>
> I don't know the story from the beginning.
I've forgotten. I don't recall seeing any bug reports which this patch
might fix.
> Are there any issues with
> this patch aside the compile error that was caused if CONFIG_PCI is not
> enabled? The compile error should be fixed and the rest looks ok on the
> first view.
I just did a PCI=n, EISA=y build and it compiled OK.
^ permalink raw reply
* Re: 3x59x-fix-pci-resource-management.patch
From: Steffen Klassert @ 2009-08-07 8:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: Sergei Shtylyov, netdev
In-Reply-To: <20090806154223.b9b9759e.akpm@linux-foundation.org>
On Thu, Aug 06, 2009 at 03:42:23PM -0700, Andrew Morton wrote:
>
> Guys, I seem to have been sitting on the below patch for, err, three years.
>
> I generally do this because there's some issue which needs to be
> addressed, but the patch didn't address it right.
>
> Can we please have a revisit and work out what we should do with this?
>
I don't know the story from the beginning. Are there any issues with
this patch aside the compile error that was caused if CONFIG_PCI is not
enabled? The compile error should be fixed and the rest looks ok on the
first view.
^ permalink raw reply
* [PATCH] f_phonet: use page-sized rather than MTU-sized RX buffers
From: Rémi Denis-Courmont @ 2009-08-07 7:56 UTC (permalink / raw)
To: netdev
In-Reply-To: <1249631804-7438-1-git-send-email-remi.denis-courmont@nokia.com>
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Instead of a large (physically) linear buffer, we generate a set of
paged sk_buff, so no extra memory copy is involved. This removes
high-order allocations and saves quite a bit of memory. Phonet MTU is
65541 bytes, so the two buffers were padded to 128 kilo-bytes each.
Now, we create 17 page buffers, almost a 75% memory use reduction.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
drivers/usb/gadget/f_phonet.c | 77 +++++++++++++++++++++++++++--------------
1 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/gadget/f_phonet.c b/drivers/usb/gadget/f_phonet.c
index f4eff7c..d2de10b 100644
--- a/drivers/usb/gadget/f_phonet.c
+++ b/drivers/usb/gadget/f_phonet.c
@@ -35,6 +35,10 @@
#include "u_phonet.h"
#define PN_MEDIA_USB 0x1B
+#define MAXPACKET 512
+#if (PAGE_SIZE % MAXPACKET)
+#error MAXPACKET must divide PAGE_SIZE!
+#endif
/*-------------------------------------------------------------------------*/
@@ -45,6 +49,10 @@ struct phonet_port {
struct f_phonet {
struct usb_function function;
+ struct {
+ struct sk_buff *skb;
+ spinlock_t lock;
+ } rx;
struct net_device *dev;
struct usb_ep *in_ep, *out_ep;
@@ -52,7 +60,7 @@ struct f_phonet {
struct usb_request *out_reqv[0];
};
-static int phonet_rxq_size = 2;
+static int phonet_rxq_size = 17;
static inline struct f_phonet *func_to_pn(struct usb_function *f)
{
@@ -138,7 +146,7 @@ pn_hs_sink_desc = {
.bEndpointAddress = USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
- .wMaxPacketSize = cpu_to_le16(512),
+ .wMaxPacketSize = cpu_to_le16(MAXPACKET),
};
static struct usb_endpoint_descriptor
@@ -298,21 +306,21 @@ static void pn_net_setup(struct net_device *dev)
static int
pn_rx_submit(struct f_phonet *fp, struct usb_request *req, gfp_t gfp_flags)
{
- struct sk_buff *skb;
- const size_t size = fp->dev->mtu;
+ struct net_device *dev = fp->dev;
+ struct page *page;
int err;
- skb = alloc_skb(size, gfp_flags);
- if (!skb)
+ page = __netdev_alloc_page(dev, gfp_flags);
+ if (!page)
return -ENOMEM;
- req->buf = skb->data;
- req->length = size;
- req->context = skb;
+ req->buf = page_address(page);
+ req->length = PAGE_SIZE;
+ req->context = page;
err = usb_ep_queue(fp->out_ep, req, gfp_flags);
if (unlikely(err))
- dev_kfree_skb_any(skb);
+ netdev_free_page(dev, page);
return err;
}
@@ -320,25 +328,37 @@ static void pn_rx_complete(struct usb_ep *ep, struct usb_request *req)
{
struct f_phonet *fp = ep->driver_data;
struct net_device *dev = fp->dev;
- struct sk_buff *skb = req->context;
+ struct page *page = req->context;
+ struct sk_buff *skb;
+ unsigned long flags;
int status = req->status;
switch (status) {
case 0:
- if (unlikely(!netif_running(dev)))
- break;
- if (unlikely(req->actual < 1))
+ spin_lock_irqsave(&fp->rx.lock, flags);
+ skb = fp->rx.skb;
+ if (!skb)
+ skb = fp->rx.skb = netdev_alloc_skb(dev, 12);
+ if (req->actual < req->length) /* Last fragment */
+ fp->rx.skb = NULL;
+ spin_unlock_irqrestore(&fp->rx.lock, flags);
+
+ if (unlikely(!skb))
break;
- skb_put(skb, req->actual);
- skb->protocol = htons(ETH_P_PHONET);
- skb_reset_mac_header(skb);
- __skb_pull(skb, 1);
- skb->dev = dev;
- dev->stats.rx_packets++;
- dev->stats.rx_bytes += skb->len;
-
- netif_rx(skb);
- skb = NULL;
+ skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, 0,
+ req->actual);
+ page = NULL;
+
+ if (req->actual < req->length) { /* Last fragment */
+ skb->protocol = htons(ETH_P_PHONET);
+ skb_reset_mac_header(skb);
+ pskb_pull(skb, 1);
+ skb->dev = dev;
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += skb->len;
+
+ netif_rx(skb);
+ }
break;
/* Do not resubmit in these cases: */
@@ -356,8 +376,8 @@ static void pn_rx_complete(struct usb_ep *ep, struct usb_request *req)
break;
}
- if (skb)
- dev_kfree_skb_any(skb);
+ if (page)
+ netdev_free_page(dev, page);
if (req)
pn_rx_submit(fp, req, GFP_ATOMIC);
}
@@ -375,6 +395,10 @@ static void __pn_reset(struct usb_function *f)
usb_ep_disable(fp->out_ep);
usb_ep_disable(fp->in_ep);
+ if (fp->rx.skb) {
+ dev_kfree_skb_irq(fp->rx.skb);
+ fp->rx.skb = NULL;
+ }
}
static int pn_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
@@ -573,6 +597,7 @@ int __init phonet_bind_config(struct usb_configuration *c)
fp->function.set_alt = pn_set_alt;
fp->function.get_alt = pn_get_alt;
fp->function.disable = pn_disconnect;
+ spin_lock_init(&fp->rx.lock);
err = usb_add_function(c, &fp->function);
if (err)
--
1.6.0.4
^ permalink raw reply related
* [PATCH] f_phonet: lock-less MTU change
From: Rémi Denis-Courmont @ 2009-08-07 7:56 UTC (permalink / raw)
To: netdev
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
With the current driver, the MTU is purely indicative, so there is no
need to synchronize with the receive path.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
drivers/usb/gadget/f_phonet.c | 14 ++------------
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/f_phonet.c b/drivers/usb/gadget/f_phonet.c
index d17f108..f4eff7c 100644
--- a/drivers/usb/gadget/f_phonet.c
+++ b/drivers/usb/gadget/f_phonet.c
@@ -261,20 +261,10 @@ out:
static int pn_net_mtu(struct net_device *dev, int new_mtu)
{
- struct phonet_port *port = netdev_priv(dev);
- unsigned long flags;
- int err = -EBUSY;
-
if ((new_mtu < PHONET_MIN_MTU) || (new_mtu > PHONET_MAX_MTU))
return -EINVAL;
-
- spin_lock_irqsave(&port->lock, flags);
- if (!netif_carrier_ok(dev)) {
- dev->mtu = new_mtu;
- err = 0;
- }
- spin_unlock_irqrestore(&port->lock, flags);
- return err;
+ dev->mtu = new_mtu;
+ return 0;
}
static const struct net_device_ops pn_netdev_ops = {
--
1.6.0.4
^ permalink raw reply related
* [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: Jussi Maki @ 2009-08-07 7:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090806.104034.186857842.davem@davemloft.net>
This patch fixes hash collisions in cases where number
of entries have incrementing IP source and destination addresses
from single respective subnets (i.e. 192.168.0.1-172.16.0.1,
192.168.0.2-172.16.0.2, and so on.).
Signed-off-by: Jussi Maki <joamaki@gmail.com>
---
net/xfrm/xfrm_hash.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index d401dc8..e5195c9 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -16,7 +16,7 @@ static inline unsigned int __xfrm6_addr_hash(xfrm_address_t *addr)
static inline unsigned int __xfrm4_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
{
- return ntohl(daddr->a4 ^ saddr->a4);
+ return ntohl(daddr->a4 + saddr->a4);
}
static inline unsigned int __xfrm6_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
--
1.5.6.5
^ permalink raw reply related
* Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less restrictive
From: Rémi Denis-Courmont @ 2009-08-07 6:52 UTC (permalink / raw)
To: ext Oliver Hartkopp, netdev@vger.kernel.org
Cc: Luotao Fu, socketcan-users@lists.berlios.de, Michael Olbrich
In-Reply-To: <4A7B0957.5020808@hartkopp.net>
Moving to netdev....
On Thursday 06 August 2009 19:48:23 ext Oliver Hartkopp wrote:
> The CAN applications can rely on getting proper CAN frames with this check.
> It was introduced some time ago together with several other sanity checks -
> even on the TX path.
>
> The CAN core *only* consumes skbuffs originated from a CAN netdevice
> (ARPHRD_CAN).
>
> When this BUG() triggers, someone provided a definitely broken *CAN*
> network driver, and this needs to be fixed on that level. It is really not
> that problematic to ensure proper CAN frames on driver level ... this
> sanity check should not be needed to be performed by every single
> application.
AFAIK, the TUN driver can inject layer-2 frames of any type, any size and any
content from userspace into the packet type handler. Sure enough, you need
CAP_NET_ADMIN and r/w access to /dev/net/tun but is it sufficient to bring the
system down?
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [PATCH net-2.6] can: Fix raw_getname() leak
From: Oliver Hartkopp @ 2009-08-07 6:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4A7BC938.8010504@gmail.com>
Eric Dumazet wrote:
> raw_getname() can leak 10 bytes of kernel memory to user
>
> (two bytes hole between can_family and can_ifindex,
> 8 bytes at the end of sockaddr_can structure)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Oliver Hartkopp <oliver@hartkopp.net>
Thanks Eric!
> ---
> diff --git a/net/can/raw.c b/net/can/raw.c
> index f4cc445..db3152d 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c
> @@ -401,6 +401,7 @@ static int raw_getname(struct socket *sock, struct sockaddr *uaddr,
> if (peer)
> return -EOPNOTSUPP;
>
> + memset(addr, 0, sizeof(*addr));
> addr->can_family = AF_CAN;
> addr->can_ifindex = ro->ifindex;
>
^ 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