* Re: net-2.6.24 plans
From: John W. Linville @ 2007-09-19 1:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, netdev, jgarzik
In-Reply-To: <20070918032328.GB3875@tuxdriver.com>
On Mon, Sep 17, 2007 at 11:23:28PM -0400, John W. Linville wrote:
> On Mon, Sep 17, 2007 at 04:49:29PM -0700, Andrew Morton wrote:
> > On Mon, 17 Sep 2007 19:18:30 -0400
> > "John W. Linville" <linville@tuxdriver.com> wrote:
> >
> > > P.S. Andrew, I'll send you a link to a new git-wireless.patch --
> > > I'm sure you don't want a complicated git invocation... Until then,
> > > I don't think you should try pulling wireless-dev...
> Anyway, I do have prepared an omnibus patch for you:
Since Dave merged the drivers I sent him, the new omnibus patch you
want is this:
http://www.kernel.org/pub/linux/kernel/people/linville/git-wireless-2007-09-18.patch
The good news is that it is 1/4 the size of its predecessor!
Hth!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH 1/2] IPoIB: Fix unregister_netdev hang
From: Krishna Kumar2 @ 2007-09-19 3:23 UTC (permalink / raw)
To: Roland Dreier; +Cc: davem, general, netdev
In-Reply-To: <adalkb4kq0j.fsf@cisco.com>
Hi Roland,
Roland Dreier <rdreier@cisco.com> wrote on 09/18/2007 07:57:24 PM:
> > While using IPoIB over EHCA (rc6 bits), unregister_netdev hangs with
>
> I don't think you're actually using rc6 bits, since in your patch you
have:
>
> > -poll_more:
>
> and I think that is only in Dave's net-2.6.24 tree now, right?
Nope, that was what I downloaded yesterday:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
EXTRAVERSION =-rc6
NAME = Pink Farting Weasel
> > + if (likely(!ib_req_notify_cq(priv->cq,
> > +
IB_CQ_NEXT_COMP |
> > +
IB_CQ_REPORT_MISSED_EVENTS)))
>
> It is possible for an interrupt to happen immediately right here,
> before the netif_rx_complete(), so that netif_rx_schedule() gets
> called while we are still on the poll list.
>
> > + netif_rx_complete(dev, napi);
To be clear, netif_rx_schedule while we are still in the poll list will not
do any harm as it does nothing since NAPI_STATE_SCHED is still set (cleared
by netif_rx_complete which has not yet run). Effectively we lost/delayed
processing an interrupt, if I understood the code right.
I agree with you on the new patch.
thanks,
- KK
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/2] IPoIB: Fix unregister_netdev hang
From: Roland Dreier @ 2007-09-19 3:30 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: netdev, davem, general
In-Reply-To: <OF402F2662.AACCDAF2-ON6525735B.00108C17-6525735B.0012AB74@in.ibm.com>
> > and I think that is only in Dave's net-2.6.24 tree now, right?
>
> Nope, that was what I downloaded yesterday:
>
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 23
> EXTRAVERSION =-rc6
> NAME = Pink Farting Weasel
Please double check your tree. I just very carefully looked at my
trees, and the poll_more: label is added in commit 6b460a71 ("[NET]:
Make NAPI polling independent of struct net_device objects.") which is
only in the net-2.6.24 tree. Of course Dave did not change the
version information in the Makefile since he wouldn't want Linus to
pick up any extra strange changes when he pulls, so a net-2.6.24 tree
will look like 2.6.23-rc6 as you quoted.
And the refcounting bug I fixed is only in net-2.6.24.
> To be clear, netif_rx_schedule while we are still in the poll list will not
> do any harm as it does nothing since NAPI_STATE_SCHED is still set (cleared
> by netif_rx_complete which has not yet run). Effectively we lost/delayed
> processing an interrupt, if I understood the code right.
Right, we lose an interrupt, and since the CQ events are one-shot, we
never get another one, and the interface is effectively dead.
- R.
^ permalink raw reply
* [RESEND][PATCH 0/4 Rev-3] Age Entry For IPv4 & IPv6 Route Table
From: Varun Chandramohan @ 2007-09-19 3:53 UTC (permalink / raw)
To: davem; +Cc: netdev, kaber, socketcan, shemminger, krkumar2, tgraf, varuncha
Hi Dave,
Iam resending the patch set again. Let me know if you need anything else.
Regards,
Varun
Original Comment:
According to the RFC 4292 (IP Forwarding Table MIB) there is a need for an age entry for all the routes in therouting table. The entry in the RFC is inetCidrRouteAge and oid is inetCidrRouteAge.1.10.
Many snmp application require this age entry. So iam adding the age field in the routing table for ipv4 and ipv6 and providing the interface for this value netlink.
I made a note of changes i made as per the suggestions given in the community. Here is the changelog.
Changelog since ver 1:
---------------------
Changes Suggestion
1)Change in the interface from proc to netlink.
It was not approved by David Miller and Yoshifuji. David Miller & Yoshifuji
2)Change from jiffies to timeval. Eric Dumazet
3)Rounding up timeval Patrick McHardy, Oliver Hartkopp
Eric Dumazet.
4)Relocate timeval_to_sec Stephen Hemminger, Krishna Kumar
5)Using macro RT6_GET_ROUTE_INFO Krishna Kumar
6)Add proper comment for timeval_to_sec Eric Dumazet
7)Add proper comment for timeval insertion Thomas Graf
Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
---
^ permalink raw reply
* [RESEND][PATCH 1/4 Rev-3] New attribute RTA_AGE
From: Varun Chandramohan @ 2007-09-19 3:53 UTC (permalink / raw)
To: davem; +Cc: netdev, kaber, socketcan, shemminger, krkumar2, tgraf, varuncha
A new attribute RTA_AGE is added for the age value to be exported to userlevel using netlink
Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
---
include/linux/rtnetlink.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index c91476c..68046a4 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -263,6 +263,7 @@ enum rtattr_type_t
RTA_SESSION,
RTA_MP_ALGO, /* no longer used */
RTA_TABLE,
+ RTA_AGE,
__RTA_MAX
};
--
1.4.3.4
^ permalink raw reply related
* [RESEND][PATCH 2/4 Rev-3] Add new timeval_to_sec function
From: Varun Chandramohan @ 2007-09-19 3:54 UTC (permalink / raw)
To: davem; +Cc: netdev, kaber, socketcan, shemminger, krkumar2, tgraf, varuncha
A new function for converting timeval to time_t is added in netlink.h. Its a common function used in differentplaces. The reason for adding this function in netlink.h is that its used by netlink for stats purpose.
Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
---
include/net/netlink.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index d7b824b..f86cc59 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -1100,4 +1100,17 @@ static inline int nla_validate_nested(st
#define nla_for_each_nested(pos, nla, rem) \
nla_for_each_attr(pos, nla_data(nla), nla_len(nla), rem)
+/**
+ * timeval_to_sec - Convert timeval to seconds
+ * @tv: pointer to the timeval variable to be converted
+ *
+ * Returns the seconds representation of timeval parameter.
+ * Note : Here we round up the value. We dont need accuracy.
+ * This is mainly used in netlink for stats purpose.
+ */
+static inline time_t timeval_to_sec(const struct timeval *tv)
+{
+ return (tv->tv_sec + (tv->tv_usec ? 1 : 0));
+}
+
#endif
--
1.4.3.4
^ permalink raw reply related
* [RESEND][PATCH 3/4 Rev-3] Initilize and populate age field
From: Varun Chandramohan @ 2007-09-19 3:54 UTC (permalink / raw)
To: davem; +Cc: netdev, kaber, socketcan, shemminger, krkumar2, tgraf, varuncha
The age field is filled with the current time at the time of creation of the route. When the routes are dumped
then the age value stored in the route structure is subtracted from the current time value and the difference is the age expressed in secs.
Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
---
net/ipv4/fib_hash.c | 3 +++
net/ipv4/fib_lookup.h | 3 ++-
net/ipv4/fib_semantics.c | 20 +++++++++++++++++---
net/ipv4/fib_trie.c | 1 +
4 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
index 9ad1d9f..228ab27 100644
--- a/net/ipv4/fib_hash.c
+++ b/net/ipv4/fib_hash.c
@@ -448,6 +448,7 @@ static int fn_hash_insert(struct fib_tab
fa->fa_info = fi;
fa->fa_type = cfg->fc_type;
fa->fa_scope = cfg->fc_scope;
+ fa->fa_age = 0;
state = fa->fa_state;
fa->fa_state &= ~FA_S_ACCESSED;
fib_hash_genid++;
@@ -507,6 +508,7 @@ static int fn_hash_insert(struct fib_tab
new_fa->fa_type = cfg->fc_type;
new_fa->fa_scope = cfg->fc_scope;
new_fa->fa_state = 0;
+ new_fa->fa_age = 0;
/*
* Insert new entry to the list.
@@ -697,6 +699,7 @@ fn_hash_dump_bucket(struct sk_buff *skb,
f->fn_key,
fz->fz_order,
fa->fa_tos,
+ &fa->fa_age,
fa->fa_info,
NLM_F_MULTI) < 0) {
cb->args[4] = i;
diff --git a/net/ipv4/fib_lookup.h b/net/ipv4/fib_lookup.h
index eef9eec..c9145b5 100644
--- a/net/ipv4/fib_lookup.h
+++ b/net/ipv4/fib_lookup.h
@@ -13,6 +13,7 @@ struct fib_alias {
u8 fa_type;
u8 fa_scope;
u8 fa_state;
+ time_t fa_age;
};
#define FA_S_ACCESSED 0x01
@@ -27,7 +28,7 @@ extern struct fib_info *fib_create_info(
extern int fib_nh_match(struct fib_config *cfg, struct fib_info *fi);
extern int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
u32 tb_id, u8 type, u8 scope, __be32 dst,
- int dst_len, u8 tos, struct fib_info *fi,
+ int dst_len, u8 tos, time_t *age, struct fib_info *fi,
unsigned int);
extern void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
int dst_len, u32 tb_id, struct nl_info *info,
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index c434119..1e56611 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -278,7 +278,8 @@ static inline size_t fib_nlmsg_size(stru
+ nla_total_size(4) /* RTA_TABLE */
+ nla_total_size(4) /* RTA_DST */
+ nla_total_size(4) /* RTA_PRIORITY */
- + nla_total_size(4); /* RTA_PREFSRC */
+ + nla_total_size(4) /* RTA_PREFSRC */
+ + nla_total_size(4); /*RTA_AGE*/
/* space for nested metrics */
payload += nla_total_size((RTAX_MAX * nla_total_size(4)));
@@ -313,7 +314,7 @@ void rtmsg_fib(int event, __be32 key, st
err = fib_dump_info(skb, info->pid, seq, event, tb_id,
fa->fa_type, fa->fa_scope, key, dst_len,
- fa->fa_tos, fa->fa_info, nlm_flags);
+ fa->fa_tos, &fa->fa_age, fa->fa_info, nlm_flags);
if (err < 0) {
/* -EMSGSIZE implies BUG in fib_nlmsg_size() */
WARN_ON(err == -EMSGSIZE);
@@ -940,11 +941,12 @@ __be32 __fib_res_prefsrc(struct fib_resu
}
int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
- u32 tb_id, u8 type, u8 scope, __be32 dst, int dst_len, u8 tos,
+ u32 tb_id, u8 type, u8 scope, __be32 dst, int dst_len, u8 tos, time_t *age,
struct fib_info *fi, unsigned int flags)
{
struct nlmsghdr *nlh;
struct rtmsg *rtm;
+ struct timeval tv;
nlh = nlmsg_put(skb, pid, seq, event, sizeof(*rtm), flags);
if (nlh == NULL)
@@ -985,6 +987,18 @@ int fib_dump_info(struct sk_buff *skb, u
NLA_PUT_U32(skb, RTA_FLOW, fi->fib_nh[0].nh_tclassid);
#endif
}
+
+ /* Note: The ideal place to fill up the time value for a newely created route will be
+ ** in fn_hash_insert(). But we are delaying the time insert procedure to avoid calling
+ ** do_gettimeofday() twice.
+ */
+ do_gettimeofday(&tv);
+ if (!*age) {
+ *age = timeval_to_sec(&tv);
+ NLA_PUT_U32(skb, RTA_AGE, *age);
+ } else {
+ NLA_PUT_U32(skb, RTA_AGE, timeval_to_sec(&tv) - *age);
+ }
#ifdef CONFIG_IP_ROUTE_MULTIPATH
if (fi->fib_nhs > 1) {
struct rtnexthop *rtnh;
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 52b2891..82a8bac 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1892,6 +1892,7 @@ static int fn_trie_dump_fa(t_key key, in
xkey,
plen,
fa->fa_tos,
+ &fa->fa_age,
fa->fa_info, 0) < 0) {
cb->args[4] = i;
return -1;
--
1.4.3.4
^ permalink raw reply related
* [RESEND][PATCH 4/4 Rev-3] Initialize and fill IPv6 route age
From: Varun Chandramohan @ 2007-09-19 3:55 UTC (permalink / raw)
To: davem; +Cc: netdev, kaber, socketcan, shemminger, krkumar2, tgraf, varuncha
The age field of the ipv6 route structures are initilized with the current timeval at the time of route
creation. When the route dump is called the route age value stored in the structure is subtracted from the
present timeval and the difference is passed on as the route age.
Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
---
include/net/ip6_fib.h | 1 +
include/net/ip6_route.h | 3 +++
net/ipv6/addrconf.c | 5 +++++
net/ipv6/route.c | 24 ++++++++++++++++++++----
4 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index c48ea87..e30a1cf 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -98,6 +98,7 @@ struct rt6_info
u32 rt6i_flags;
u32 rt6i_metric;
+ time_t rt6i_age;
atomic_t rt6i_ref;
struct fib6_table *rt6i_table;
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 5456fdd..fc9716c 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -36,6 +36,9 @@ struct route_info {
#define RT6_LOOKUP_F_REACHABLE 0x2
#define RT6_LOOKUP_F_HAS_SADDR 0x4
+#define RT6_SET_ROUTE_INFO 0x0
+#define RT6_GET_ROUTE_INFO 0x1
+
extern struct rt6_info ip6_null_entry;
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 91ef3be..666ec28 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4182,6 +4182,7 @@ EXPORT_SYMBOL(unregister_inet6addr_notif
int __init addrconf_init(void)
{
+ struct timeval tv;
int err = 0;
/* The addrconf netdev notifier requires that loopback_dev
@@ -4209,10 +4210,14 @@ int __init addrconf_init(void)
if (err)
return err;
+ do_gettimeofday(&tv);
ip6_null_entry.rt6i_idev = in6_dev_get(&loopback_dev);
+ ip6_null_entry.rt6i_age = timeval_to_sec(&tv);
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
ip6_prohibit_entry.rt6i_idev = in6_dev_get(&loopback_dev);
+ ip6_prohibit_entry.rt6i_age = timeval_to_sec(&tv);
ip6_blk_hole_entry.rt6i_idev = in6_dev_get(&loopback_dev);
+ ip6_blk_hole_entry.rt6i_age = timeval_to_sec(&tv);
#endif
register_netdevice_notifier(&ipv6_dev_notf);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 55ea80f..9954187 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -600,7 +600,14 @@ static int __ip6_ins_rt(struct rt6_info
{
int err;
struct fib6_table *table;
+ struct timeval tv;
+ do_gettimeofday(&tv);
+ /* Update the timeval for new routes
+ * We add it here to make it common irrespective
+ * of how the new route is added.
+ */
+ rt->rt6i_age = timeval_to_sec(&tv);
table = rt->rt6i_table;
write_lock_bh(&table->tb6_lock);
err = fib6_add(&table->tb6_root, rt, info);
@@ -2112,6 +2119,7 @@ static inline size_t rt6_nlmsg_size(void
+ nla_total_size(4) /* RTA_IIF */
+ nla_total_size(4) /* RTA_OIF */
+ nla_total_size(4) /* RTA_PRIORITY */
+ + nla_total_size(4) /*RTA_AGE*/
+ RTAX_MAX * nla_total_size(4) /* RTA_METRICS */
+ nla_total_size(sizeof(struct rta_cacheinfo));
}
@@ -2119,10 +2127,11 @@ static inline size_t rt6_nlmsg_size(void
static int rt6_fill_node(struct sk_buff *skb, struct rt6_info *rt,
struct in6_addr *dst, struct in6_addr *src,
int iif, int type, u32 pid, u32 seq,
- int prefix, unsigned int flags)
+ int prefix, unsigned int flags, int dumpflg)
{
struct rtmsg *rtm;
struct nlmsghdr *nlh;
+ struct timeval tv;
long expires;
u32 table;
@@ -2186,6 +2195,13 @@ static int rt6_fill_node(struct sk_buff
if (ipv6_get_saddr(&rt->u.dst, dst, &saddr_buf) == 0)
NLA_PUT(skb, RTA_PREFSRC, 16, &saddr_buf);
}
+
+ if (dumpflg == RT6_GET_ROUTE_INFO) {
+ do_gettimeofday(&tv);
+ NLA_PUT_U32(skb, RTA_AGE, timeval_to_sec(&tv) - rt->rt6i_age);
+ } else {
+ NLA_PUT_U32(skb, RTA_AGE, rt->rt6i_age);
+ }
if (rtnetlink_put_metrics(skb, rt->u.dst.metrics) < 0)
goto nla_put_failure;
@@ -2223,7 +2239,7 @@ int rt6_dump_route(struct rt6_info *rt,
return rt6_fill_node(arg->skb, rt, NULL, NULL, 0, RTM_NEWROUTE,
NETLINK_CB(arg->cb->skb).pid, arg->cb->nlh->nlmsg_seq,
- prefix, NLM_F_MULTI);
+ prefix, NLM_F_MULTI, RT6_GET_ROUTE_INFO);
}
static int inet6_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr* nlh, void *arg)
@@ -2288,7 +2304,7 @@ static int inet6_rtm_getroute(struct sk_
err = rt6_fill_node(skb, rt, &fl.fl6_dst, &fl.fl6_src, iif,
RTM_NEWROUTE, NETLINK_CB(in_skb).pid,
- nlh->nlmsg_seq, 0, 0);
+ nlh->nlmsg_seq, 0, 0, RT6_GET_ROUTE_INFO);
if (err < 0) {
kfree_skb(skb);
goto errout;
@@ -2317,7 +2333,7 @@ void inet6_rt_notify(int event, struct r
if (skb == NULL)
goto errout;
- err = rt6_fill_node(skb, rt, NULL, NULL, 0, event, pid, seq, 0, 0);
+ err = rt6_fill_node(skb, rt, NULL, NULL, 0, event, pid, seq, 0, 0, RT6_SET_ROUTE_INFO);
if (err < 0) {
/* -EMSGSIZE implies BUG in rt6_nlmsg_size() */
WARN_ON(err == -EMSGSIZE);
--
1.4.3.4
^ permalink raw reply related
* [ofa-general] Re: [PATCH 1/2] IPoIB: Fix unregister_netdev hang
From: Krishna Kumar2 @ 2007-09-19 4:24 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, davem, general
In-Reply-To: <adak5qnjpr7.fsf@cisco.com>
Hi Roland,
> Please double check your tree. I just very carefully looked at my
> trees, and the poll_more: label is added in commit 6b460a71 ("[NET]:
> Make NAPI polling independent of struct net_device objects.") which is
> only in the net-2.6.24 tree. Of course Dave did not change the
> version information in the Makefile since he wouldn't want Linus to
> pick up any extra strange changes when he pulls, so a net-2.6.24 tree
> will look like 2.6.23-rc6 as you quoted.
>
> And the refcounting bug I fixed is only in net-2.6.24.
You are absolutely right. My wording was incorrect, I should have said
net-2.6.24 (which is *at* rev rc6).
> > To be clear, netif_rx_schedule while we are still in the poll list
will not
> > do any harm as it does nothing since NAPI_STATE_SCHED is still set
(cleared
> > by netif_rx_complete which has not yet run). Effectively we
lost/delayed
> > processing an interrupt, if I understood the code right.
>
> Right, we lose an interrupt, and since the CQ events are one-shot, we
> never get another one, and the interface is effectively dead.
Thanks,
- KK
^ permalink raw reply
* Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
From: Joe Perches @ 2007-09-19 4:50 UTC (permalink / raw)
To: David Miller; +Cc: johannes, netdev, akpm, jgarzik
In-Reply-To: <1190081655.19708.255.camel@localhost>
On Mon, 2007-09-17 at 19:14 -0700, Joe Perches wrote:
> On Mon, 2007-09-17 at 19:05 -0700, David Miller wrote:
> > Anyways, it would indeed help if you could rebase the patch
> > against net-2.6.24 It would save me a ton of time.
>
> I'll rebase it tomorrow against whatever's in
> your current net-2.6.24.
I rebased against yesterday's net-2.6.24
Please pull from:
git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-fordave
drivers/net/3c503.c | 4 +-
drivers/net/3c505.c | 10 +-
drivers/net/3c507.c | 6 +-
drivers/net/3c509.c | 18 +--
drivers/net/3c515.c | 4 +-
drivers/net/3c523.c | 22 +--
drivers/net/3c527.c | 7 +-
drivers/net/3c59x.c | 7 +-
drivers/net/8139cp.c | 8 +-
drivers/net/8139too.c | 8 +-
drivers/net/82596.c | 18 +--
drivers/net/a2065.c | 6 +-
drivers/net/ac3200.c | 8 +-
drivers/net/acenic.c | 7 +-
drivers/net/amd8111e.c | 12 +-
drivers/net/apne.c | 9 +-
drivers/net/ariadne.c | 44 +++---
drivers/net/arm/am79c961a.c | 8 +-
drivers/net/arm/at91_ether.c | 18 +-
drivers/net/arm/ether1.c | 8 +-
drivers/net/arm/ether3.c | 8 +-
drivers/net/arm/etherh.c | 8 +-
drivers/net/at1700.c | 4 +-
drivers/net/atarilance.c | 43 +++---
drivers/net/atp.c | 8 +-
drivers/net/b44.c | 9 +-
drivers/net/bmac.c | 6 +-
drivers/net/bnx2.c | 12 +-
drivers/net/bonding/bond_main.c | 34 ++---
drivers/net/bonding/bond_sysfs.c | 11 +-
drivers/net/cassini.c | 11 +-
drivers/net/cris/eth_v10.c | 8 +-
drivers/net/cs89x0.c | 15 +--
drivers/net/de600.c | 6 +-
drivers/net/de620.c | 8 +-
drivers/net/declance.c | 14 +-
drivers/net/depca.c | 13 +-
drivers/net/dgrs.c | 18 +--
drivers/net/dl2k.c | 7 +-
drivers/net/dm9000.c | 9 +-
drivers/net/e100.c | 9 +-
drivers/net/e1000/e1000_main.c | 5 +-
drivers/net/eepro.c | 5 +-
drivers/net/eepro100.c | 9 +-
drivers/net/epic100.c | 9 +-
drivers/net/es3210.c | 22 ++--
drivers/net/ewrk3.c | 16 +--
drivers/net/fealnx.c | 9 +-
drivers/net/fec.c | 7 +-
drivers/net/forcedeth.c | 12 +-
drivers/net/gianfar.c | 7 +-
drivers/net/hamachi.c | 8 +-
drivers/net/hamradio/bpqether.c | 23 +--
drivers/net/hp-plus.c | 6 +-
drivers/net/hp.c | 5 +-
drivers/net/hp100.c | 6 +-
drivers/net/hydra.c | 7 +-
drivers/net/ibm_emac/ibm_emac_core.c | 14 +-
drivers/net/ibmlana.c | 6 +-
drivers/net/ibmveth.c | 9 +-
drivers/net/ioc3-eth.c | 12 +-
drivers/net/isa-skeleton.c | 5 +-
drivers/net/jazzsonic.c | 10 +-
drivers/net/lance.c | 6 +-
drivers/net/lguest_net.c | 4 +-
drivers/net/lib82596.c | 18 +--
drivers/net/lne390.c | 9 +-
drivers/net/mac89x0.c | 11 +-
drivers/net/macb.c | 6 +-
drivers/net/mace.c | 9 +-
drivers/net/macmace.c | 6 +-
drivers/net/macsonic.c | 21 +--
drivers/net/meth.c | 6 +-
drivers/net/mv643xx_eth.c | 5 +-
drivers/net/mvme147.c | 11 +-
drivers/net/myri10ge/myri10ge.c | 11 +-
drivers/net/myri_sbus.c | 29 ++---
drivers/net/natsemi.c | 11 +-
drivers/net/ne-h8300.c | 8 +-
drivers/net/ne.c | 5 +-
drivers/net/ne2.c | 17 +--
drivers/net/ne2k-pci.c | 11 +-
drivers/net/ne3210.c | 11 +-
drivers/net/netconsole.c | 14 +-
drivers/net/netxen/netxen_nic_main.c | 13 +-
drivers/net/netxen/netxen_nic_niu.c | 14 +-
drivers/net/ni5010.c | 4 +-
drivers/net/ns83820.c | 7 +-
drivers/net/pasemi_mac.c | 6 +-
drivers/net/pci-skeleton.c | 9 +-
drivers/net/pcmcia/3c574_cs.c | 9 +-
drivers/net/pcmcia/3c589_cs.c | 10 +-
drivers/net/pcmcia/axnet_cs.c | 9 +-
drivers/net/pcmcia/fmvj18x_cs.c | 8 +-
drivers/net/pcmcia/nmclan_cs.c | 9 +-
drivers/net/pcmcia/pcnet_cs.c | 7 +-
drivers/net/pcmcia/smc91c92_cs.c | 8 +-
drivers/net/pcmcia/xirc2ps_cs.c | 9 +-
drivers/net/pppoe.c | 8 +-
drivers/net/ps3_gelic_net.c | 7 +-
drivers/net/qla3xxx.c | 7 +-
drivers/net/rionet.c | 6 +-
drivers/net/rrunner.c | 8 +-
drivers/net/s2io.c | 11 +-
drivers/net/sb1250-mac.c | 7 +-
drivers/net/seeq8005.c | 4 +-
drivers/net/sgiseeq.c | 6 +-
drivers/net/sis190.c | 10 +-
drivers/net/sis900.c | 9 +-
drivers/net/skge.c | 7 +-
drivers/net/sky2.c | 7 +-
drivers/net/smc-mca.c | 8 +-
drivers/net/smc-ultra.c | 8 +-
drivers/net/smc-ultra32.c | 8 +-
drivers/net/smc9194.c | 7 +-
drivers/net/smc91x.c | 9 +-
drivers/net/starfire.c | 26 ++--
drivers/net/sun3lance.c | 36 ++---
drivers/net/sunbmac.c | 8 +-
drivers/net/sundance.c | 10 +-
drivers/net/sungem.c | 12 +-
drivers/net/sunhme.c | 12 +-
drivers/net/sunlance.c | 9 +-
drivers/net/tokenring/abyss.c | 12 +-
drivers/net/tokenring/ibmtr.c | 26 ++--
drivers/net/tokenring/lanstreamer.c | 64 +++-----
drivers/net/tokenring/madgemc.c | 19 +--
drivers/net/tokenring/olympic.c | 138 +++++++---------
drivers/net/tokenring/proteon.c | 8 +-
drivers/net/tokenring/skisa.c | 8 +-
drivers/net/tokenring/tmspci.c | 10 +-
drivers/net/tsi108_eth.c | 7 +-
drivers/net/tulip/de2104x.c | 9 +-
drivers/net/tulip/de4x5.c | 33 +---
drivers/net/tulip/dmfe.c | 15 +-
drivers/net/tulip/tulip_core.c | 15 +-
drivers/net/tulip/uli526x.c | 9 +-
drivers/net/tulip/winbond-840.c | 29 ++--
drivers/net/tulip/xircom_cb.c | 7 +-
drivers/net/tun.c | 33 ++---
drivers/net/typhoon.c | 10 +-
drivers/net/usb/pegasus.c | 11 +-
drivers/net/usb/usbnet.c | 8 +-
drivers/net/via-rhine.c | 13 +-
drivers/net/wd.c | 7 +-
drivers/net/wireless/adm8211.c | 5 +-
drivers/net/wireless/airo.c | 32 ++---
drivers/net/wireless/arlan-main.c | 23 ++--
drivers/net/wireless/atmel.c | 7 +-
drivers/net/wireless/bcm43xx/bcm43xx.h | 6 -
drivers/net/wireless/hostap/hostap_80211_rx.c | 49 ++++---
drivers/net/wireless/hostap/hostap_80211_tx.c | 13 +-
drivers/net/wireless/hostap/hostap_ap.c | 198 +++++++++++++----------
drivers/net/wireless/hostap/hostap_common.h | 3 -
drivers/net/wireless/hostap/hostap_hw.c | 11 +-
drivers/net/wireless/hostap/hostap_info.c | 17 ++-
drivers/net/wireless/hostap/hostap_ioctl.c | 15 +-
drivers/net/wireless/hostap/hostap_main.c | 30 ++--
drivers/net/wireless/hostap/hostap_proc.c | 15 +-
drivers/net/wireless/ipw2100.c | 48 +++---
drivers/net/wireless/ipw2200.c | 207 +++++++++++++-----------
drivers/net/wireless/libertas/assoc.c | 19 ++-
drivers/net/wireless/libertas/cmdresp.c | 5 +-
drivers/net/wireless/libertas/debugfs.c | 5 +-
drivers/net/wireless/libertas/join.c | 16 ++-
drivers/net/wireless/libertas/main.c | 12 +-
drivers/net/wireless/libertas/scan.c | 14 +-
drivers/net/wireless/libertas/wext.c | 5 +-
drivers/net/wireless/netwave_cs.c | 14 +-
drivers/net/wireless/orinoco.c | 7 +-
drivers/net/wireless/prism54/isl_ioctl.c | 50 ++----
drivers/net/wireless/ray_cs.c | 13 +-
drivers/net/wireless/rtl8187_dev.c | 5 +-
drivers/net/wireless/wavelan.c | 53 +++----
drivers/net/wireless/wavelan_cs.c | 54 +++----
drivers/net/wireless/wl3501_cs.c | 22 ++--
drivers/net/wireless/zd1211rw/zd_chip.c | 3 +-
drivers/net/wireless/zd1211rw/zd_mac.c | 8 +-
drivers/net/yellowfin.c | 19 +--
drivers/net/znet.c | 11 +-
drivers/net/zorro8390.c | 15 +-
include/linux/if_ether.h | 7 +
include/net/ieee80211.h | 5 -
include/net/mac80211.h | 4 -
net/802/tr.c | 28 ++--
net/appletalk/aarp.c | 9 +-
net/atm/br2684.c | 16 +--
net/atm/lec.c | 29 ++--
net/core/netpoll.c | 12 +-
net/core/pktgen.c | 17 +--
net/ethernet/eth.c | 8 +
net/ieee80211/ieee80211_crypt_ccmp.c | 27 ++--
net/ieee80211/ieee80211_crypt_tkip.c | 31 ++--
net/ieee80211/ieee80211_rx.c | 59 ++++---
net/ieee80211/ieee80211_wx.c | 5 +-
net/ieee80211/softmac/ieee80211softmac_assoc.c | 4 +-
net/ieee80211/softmac/ieee80211softmac_auth.c | 35 +++--
net/ieee80211/softmac/ieee80211softmac_wx.c | 5 +-
net/irda/irlan/irlan_client.c | 6 +-
net/llc/llc_proc.c | 12 +-
net/mac80211/debugfs_key.c | 3 +-
net/mac80211/debugfs_netdev.c | 3 +-
net/mac80211/debugfs_sta.c | 6 +-
net/mac80211/event.c | 5 +-
net/mac80211/ieee80211.c | 5 +-
net/mac80211/ieee80211_ioctl.c | 5 +-
net/mac80211/ieee80211_sta.c | 180 ++++++++++++---------
net/mac80211/key.c | 10 +-
net/mac80211/rc80211_simple.c | 5 +-
net/mac80211/rx.c | 102 +++++++------
net/mac80211/sta_info.c | 13 +-
net/mac80211/tkip.c | 10 +-
net/mac80211/tx.c | 32 ++--
net/mac80211/wpa.c | 19 ++-
net/tipc/eth_media.c | 4 +-
215 files changed, 1700 insertions(+), 1847 deletions(-)
^ permalink raw reply
* [ofa-general] Re: InfiniBand/RDMA merge plans for 2.6.24
From: Michael S. Tsirkin @ 2007-09-19 6:19 UTC (permalink / raw)
To: Jack Morgenstein; +Cc: netdev, Roland Dreier, general
In-Reply-To: <200709180909.50029.jackm@dev.mellanox.co.il>
> Missing from this list (IMPORTANT patch!):
> [ofa-general] [PATCH 2 of 2] IB/mlx4: Handle new FW requirement for send request prefetching, for WQE sg lists
> (Posted by me to list on Sept 4)
> {patch header:
> This is an addendum to Roland's commit 0e6e74162164d908edf7889ac66dca09e7505745
> (June 18). This addendum adds prefetch headroom marking processing for s/g segments.
>
> We write s/g segments in reverse order into the WQE, in order to guarantee
> that the first dword of all cachelines containing s/g segments is written last
> (overwriting the headroom invalidation pattern). The entire cacheline will thus
> contain valid data when the invalidation pattern is overwritten.
This actually looks like a bugfix that might even have been appropriate
for 2.6.23. Roland, do you have this patch? Can you comment on it please?
--
MST
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-09-19 6:26 UTC (permalink / raw)
To: Urs Thuermann
Cc: Patrick McHardy, netdev, David Miller, Thomas Gleixner,
Oliver Hartkopp
In-Reply-To: <ygf7imnzk60.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> Now I think we should consider removing the loopback code from
> can_send() and demand from each CAN driver that it *has to* implement
> this itself.
>
I also thought about this solution, which would remove the 'loopback'
parameter in vcan.c and some loopback code in can_send().
My only concern was, that this would break with standard netdev
behaviour just to send and receive data to/from the medium.
To break with the standard behaviour might be ok here as the PF_CAN only
deals with CAN netdevs (ARPHRD_CAN) which can be seen as some closed
eco-system. But i don't know what should happen, if someone in the
future gets the idea to route CAN-frames over ethernet devices for any
reason? In this case we would have to touch every driver we'd like to
support.
IMO it makes more sense to let the 9 lines of loopback fallback code in
can_send() than to remove it.
Oliver
^ permalink raw reply
* Re: NetXen driver causing slab corruption in -RT kernels
From: Dhananjay Phadke @ 2007-09-19 6:43 UTC (permalink / raw)
To: Vernon Mauery; +Cc: netdev, LKML
In-Reply-To: <200709181117.59041.vernux@us.ibm.com>
That "00 0e 1e ..." is netxen's mac address, so sounds like the NIC is
dumping a frame in the skb already freed (and poisoned) by the stack.
I suppose -RT kernels preempt the softirq, giving a chance for this race.
The netxen driver doesn't seem to clear the mapped address of the skb in
rx descriptor, instead it replaces it with mapped address of newly
allocated skb. Also, the rx ring is replenished in bursts (at the end of
poll routine), this can help the race if preempted in between.
I am currently reworking the rx handling, hopefully it will fix this.
Thanks for reporting in detail.
-Dhananjay
Vernon Mauery wrote:
> In doing some stress testing of the NetXen driver, I found that my machine was
> dying in all sorts of weird ways. I saw several different crashes, BUG
> messages in the TCP stack and some assert messages in the TCP stack as well.
> I really didn't think that there could be six different bugs all at once in
> the TCP/IP stack, so I started looking at possible memory corruption.
>
> I first saw this on 2.6.16-rt22 with a backported netxen driver from 2.6.22.
> I figured I should try the latest kernel, so I tried it on 2.6.23-rc6-git7
> but could not trigger the slab corruption messages with CONFIG_DEBUG_SLAB, so
> I figured the race must only exist in the -RT kernels. Next I tried
> 2.6.23-rc6-git7-rt1 (I applied patch-2.6.23-rc4-rt1 patch to 2.6.23-rc6-git7
> and fixed the 5 failing hunks). After an hour or so, lots of slab corruption
> messages showed up:
>
> Slab corruption: size-2048 start=f40c4670, len=2048
> Slab corruption: size-2048 start=f313cf48, len=2048
> Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
> Last user: [<c0166be4>](kfree+0x80/0x95)
> 010: 6b 6b 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00
> 020: 45 00 05 dc 92 ab 40 00 40 11 8a 5b 0a 02 02 03
> 030: 0a 02 02 04 80 0c 80 0d 05 c8 dc 39 00 00 00 00
> 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Prev obj: start=f313c730, len=2048
> Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> Last user: [<f8f06186>](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic])
> 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
> 010: 5a 5a 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00
> Next obj: start=f313d760, len=2048
> Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> Last user: [<f8f06186>](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic])
> 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
> 010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
> Slab corruption: size-2048 start=f395a6f0, len=2048
> Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
> Last user: [<c0166be4>](kfree+0x80/0x95)
> 010: 6b 6b 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00
> 020: 45 00 05 dc 92 ac 40 00 40 11 8a 5a 0a 02 02 03
> 030: 0a 02 02 04 80 0c 80 0d 05 c8 dc 39 00 00 00 00
> 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Next obj: start=f395af08, len=2048
> Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> Last user: [<f8f06186>](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic])
> 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
> 010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
> Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
> Last user: [<c0166be4>](kfree+0x80/0x95)
> 010: 6b 6b 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00
> 020: 45 00 05 dc 92 aa 40 00 40 11 8a 5c 0a 02 02 03
> 030: 0a 02 02 04 80 0c 80 0d 05 c8 dc 39 00 00 00 00
> 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Next obj: start=f40c4e88, len=2048
> Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> Last user: [<f8f06186>](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic])
> 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
> 010: 5a 5a 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00
>
> The stress test that I am running is basically a mixed bag of stuff I threw
> together. It runs eight concurrent netperf TCP streams and two concurrent
> UDP streams in both directions, (and on both 10GbE interfaces), ping -f in
> both directions, some more disk/cpu loads in the background and a little bit
> of NFS traffic thrown in for good measure.
>
> --Vernon
^ permalink raw reply
* Re: Pull request for 'r8169-for-jeff-20070914' branch
From: Francois Romieu @ 2007-09-19 7:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, akpm, David Gundersen, Edward Hsu
In-Reply-To: <46F04BCA.7080307@pobox.com>
Jeff Garzik <jgarzik@pobox.com> :
[...]
> For fixes, please base off of linux-2.6.git. I can't push this upstream
> immediately, since it pulls in for-2.6.24 stuff.
I will do it this evening.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/3] Blackfin EMAC driver: add function to change the MAC address
From: Bryan Wu @ 2007-09-19 7:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bryan.wu, akpm, linux-kernel, netdev, uclinux-dist-devel
In-Reply-To: <46F04C2A.20500@garzik.org>
On Wed, 2007-09-19 at 06:07 +0800, Jeff Garzik wrote:
> Bryan Wu wrote:
> >>From 157dfddae50708a716c2a42a314eccb9621d8793 Mon Sep 17 00:00:00
> 2001
> > From: Alex Landau <lirsb@yahoo.com>
> > Date: Sun, 5 Aug 2007 15:58:03 +0800
> > Subject: [PATCH] Blackfin Ethernet MAC driver: add function to
> change the MAC address
> >
> > Alex Landau writes in the forums:
> > Previously, changing the MAC address (e.g. via ifconfig) resulted
> > in a generic function to be called that only changed a variable
> in
> > memory. This patch also updated the Blackfin MAC address
> registers
> > to filter the correct new MAC.
> >
> > Signed-off-by: Alex Landau <lirsb@yahoo.com>
> > Signed-off-by: Mike Frysinger <michael.frysinger@analog.com>
> > Signed-off-by: Bryan Wu <bryan.wu@analog.com>
>
> ACK patches 1-3... but can you regenerate them against
> netdev-2.6.git#upstream (or davem/net-2.6.24.git)?
Excellent, I will resend the patch against the netdev-2.6.git#upstream
ASAP.
Thanks
-Bryan Wu
>
^ permalink raw reply
* Re: [FIX NETLINK] properly check arguments to netlink_bind()
From: Holger Eitzenberger @ 2007-09-19 7:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20070918.145331.67883847.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
>> > while going through going netlink code I found out that netlink_bind()
>> > does not properly check bind parameters. I checked both 2.6.23-rc1 as
>> > well as 2.6.16.53, both are affected.
> Firstly, you patch compares the address _pointer_ against
> the minimum length. That's obviously wrong.
True, the message send later fixed that.
> And if you check the call sites of the protocol ->bind() methods, they
> all use on-stack buffer for the address object which is at least
> MAX_SOCK_ADDR bytes in length so that the bind methods don't have to
> check the size if they don't want to.
Also true, but in that case you still end up accessing uninitialized
data. Also note that e. g. inet_bind() checks explicitely for that and
it's not clear to me why netlink_bind() is different. Maybe you just
help me figuring out.
Another point is that simply calling
bind(nl_fd, (struct sockaddr *)&an_int, sizeof(int));
will not return EINVAL but depends on the randomn data after an_int.
/holger
^ permalink raw reply
* drop association of connection-less socket
From: Ulrich Drepper @ 2007-09-19 7:28 UTC (permalink / raw)
To: netdev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Linux man page for connect(2) currently says:
Connectionless sockets may dissolve the association by connecting to
an address with the sa_family member of sockaddr set to AF_UNSPEC.
No such wording is in the POSIX definition which only says
If address is a null address for the protocol, the socket’s peer
address shall be reset.
This is not the same but seems to be what Linux implements.
The problem is that I tried to reuse a socket which has been associated
with an IPv6 address to later connect to an IPv4 address. This is part
of the getaddrinfo implementation and an effort to make it more
efficient. strace's output looks like this:
connect(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
"2001:11b8:1:0:207:e94f:ee7c:4b72", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
connect(3, {sa_family=AF_UNSPEC,
sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 28) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.72")}, 16) = 0
I.e., despite what the man page says, the second connect only reset the
address, as required by the POSIX spec. It did not reset the address
family of the socket.
What I ideally would like to see is what the Linux man page says. I.e.,
if the .sa_family field is AF_UNSPEC all, the address and address
family, is reset. Otherwise only the address association itself is reset.
Is this functionality which got lost over time? Or is the man page
wrong and this never was the case? Is this a worthwhile change?
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8M+52ijCOnn/RHQRAnTEAJ0Z/DrTkcCjpbybB5lqDad9Z0MbZwCeLZOh
u/mNfxV7uDjRsSuOj4YwuIg=
=FO70
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: bnx2 dirver's firmware images
From: Denys Vlasenko @ 2007-09-19 8:30 UTC (permalink / raw)
To: Michael Chan; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <1190145951.9540.230.camel@dell>
[-- Attachment #1: Type: text/plain, Size: 985 bytes --]
On Tuesday 18 September 2007 21:05, Michael Chan wrote:
> The bnx2 firmware changes quite frequently. A new driver quite often
> requires new firmware to work correctly. Splitting them up makes things
> difficult for the user.
sounds reasonable.
I see that bnx2 has support for unpacking gzipped binary blobs,
and it it the only such net driver (maybe the only such driver
in the entire tree, I didn't check).
This can be very useful for all other firmware images in other drivers.
Last night I prepared a patch which basically separates unpacking
function from bnx2-related code. Can you run-test attached patch?
Meanwhile I will prepare follow-on patch which actually moves this
function out of the driver and into lib/*.
Size difference:
# size */bn*.o
text data bss dec hex filename
54884 81689 6424 142997 22e95 net/bnx2.o
55276 81823 6424 143523 230a3 net.org/bnx2.o
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
[-- Attachment #2: linux-2.6.23-rc6.gunzip.patch --]
[-- Type: text/x-diff, Size: 12229 bytes --]
--- linux-2.6.23-rc6.org/drivers/net/bnx2.c Tue Sep 11 22:33:54 2007
+++ linux-2.6.23-rc6.gunzip/drivers/net/bnx2.c Wed Sep 19 00:01:19 2007
@@ -2767,93 +2767,61 @@
spin_unlock_bh(&bp->phy_lock);
}
-#define FW_BUF_SIZE 0x8000
-
+/* To be moved to generic lib/ */
static int
-bnx2_gunzip_init(struct bnx2 *bp)
+bnx2_gunzip(u8 *zbuf, int len, void **outbuf)
{
- if ((bp->gunzip_buf = vmalloc(FW_BUF_SIZE)) == NULL)
- goto gunzip_nomem1;
+ struct z_stream_s *strm;
+ void *gunzip_buf;
+ int rc;
+ int sz;
- if ((bp->strm = kmalloc(sizeof(*bp->strm), GFP_KERNEL)) == NULL)
- goto gunzip_nomem2;
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+ * is stripped, 32-bit unpacked size (LE) is prepended instead */
+ sz = *zbuf++;
+ sz = (sz << 8) + *zbuf++;
+ sz = (sz << 8) + *zbuf++;
+ sz = (sz << 8) + *zbuf++;
- bp->strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
- if (bp->strm->workspace == NULL)
+ rc = -ENOMEM;
+ gunzip_buf = vmalloc(sz);
+ if (gunzip_buf == NULL)
+ goto gunzip_nomem1;
+ strm = kmalloc(sizeof(*strm), GFP_KERNEL);
+ if (strm == NULL)
+ goto gunzip_nomem2;
+ strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
+ if (strm->workspace == NULL)
goto gunzip_nomem3;
- return 0;
+ strm->next_in = zbuf;
+ strm->avail_in = len;
+ strm->next_out = gunzip_buf;
+ strm->avail_out = sz;
-gunzip_nomem3:
- kfree(bp->strm);
- bp->strm = NULL;
+ rc = zlib_inflateInit2(strm, -MAX_WBITS);
+ if (rc == Z_OK) {
+ rc = zlib_inflate(strm, Z_FINISH);
+ if (rc == Z_OK) {
+ rc = sz - strm->avail_out;
+ *outbuf = gunzip_buf;
+ } else
+ rc = -EINVAL;
+ zlib_inflateEnd(strm);
+ } else
+ rc = -EINVAL;
+ kfree(strm->workspace);
+gunzip_nomem3:
+ kfree(strm);
gunzip_nomem2:
- vfree(bp->gunzip_buf);
- bp->gunzip_buf = NULL;
-
+ if (rc != Z_OK)
+ vfree(gunzip_buf);
gunzip_nomem1:
- printk(KERN_ERR PFX "%s: Cannot allocate firmware buffer for "
- "uncompression.\n", bp->dev->name);
- return -ENOMEM;
+ return rc; /* returns Z_OK (0) if successful */
}
static void
-bnx2_gunzip_end(struct bnx2 *bp)
-{
- kfree(bp->strm->workspace);
-
- kfree(bp->strm);
- bp->strm = NULL;
-
- if (bp->gunzip_buf) {
- vfree(bp->gunzip_buf);
- bp->gunzip_buf = NULL;
- }
-}
-
-static int
-bnx2_gunzip(struct bnx2 *bp, u8 *zbuf, int len, void **outbuf, int *outlen)
-{
- int n, rc;
-
- /* check gzip header */
- if ((zbuf[0] != 0x1f) || (zbuf[1] != 0x8b) || (zbuf[2] != Z_DEFLATED))
- return -EINVAL;
-
- n = 10;
-
-#define FNAME 0x8
- if (zbuf[3] & FNAME)
- while ((zbuf[n++] != 0) && (n < len));
-
- bp->strm->next_in = zbuf + n;
- bp->strm->avail_in = len - n;
- bp->strm->next_out = bp->gunzip_buf;
- bp->strm->avail_out = FW_BUF_SIZE;
-
- rc = zlib_inflateInit2(bp->strm, -MAX_WBITS);
- if (rc != Z_OK)
- return rc;
-
- rc = zlib_inflate(bp->strm, Z_FINISH);
-
- *outlen = FW_BUF_SIZE - bp->strm->avail_out;
- *outbuf = bp->gunzip_buf;
-
- if ((rc != Z_OK) && (rc != Z_STREAM_END))
- printk(KERN_ERR PFX "%s: Firmware decompression error: %s\n",
- bp->dev->name, bp->strm->msg);
-
- zlib_inflateEnd(bp->strm);
-
- if (rc == Z_STREAM_END)
- return 0;
-
- return rc;
-}
-
-static void
load_rv2p_fw(struct bnx2 *bp, u32 *rv2p_code, u32 rv2p_code_len,
u32 rv2p_proc)
{
@@ -2902,22 +2870,16 @@
/* Load the Text area. */
offset = cpu_reg->spad_base + (fw->text_addr - cpu_reg->mips_view_base);
if (fw->gz_text) {
- u32 text_len;
- void *text;
-
- rc = bnx2_gunzip(bp, fw->gz_text, fw->gz_text_len, &text,
- &text_len);
- if (rc)
- return rc;
-
- fw->text = text;
- }
- if (fw->gz_text) {
+ u32 *text;
int j;
+ rc = bnx2_gunzip(fw->gz_text, fw->gz_text_len, (void*) &text);
+ if (rc < 0)
+ return rc;
for (j = 0; j < (fw->text_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, cpu_to_le32(fw->text[j]));
+ REG_WR_IND(bp, offset, cpu_to_le32(text[j]));
}
+ vfree(text);
}
/* Load the Data area. */
@@ -2979,28 +2941,22 @@
{
struct cpu_reg cpu_reg;
struct fw_info *fw;
- int rc = 0;
+ int rc;
void *text;
- u32 text_len;
- if ((rc = bnx2_gunzip_init(bp)) != 0)
- return rc;
-
/* Initialize the RV2P processor. */
- rc = bnx2_gunzip(bp, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1), &text,
- &text_len);
- if (rc)
+ rc = bnx2_gunzip(bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1), &text);
+ if (rc < 0)
goto init_cpu_err;
+ load_rv2p_fw(bp, text, rc /* == len */, RV2P_PROC1);
+ vfree(text);
- load_rv2p_fw(bp, text, text_len, RV2P_PROC1);
-
- rc = bnx2_gunzip(bp, bnx2_rv2p_proc2, sizeof(bnx2_rv2p_proc2), &text,
- &text_len);
- if (rc)
+ rc = bnx2_gunzip(bnx2_rv2p_proc2, sizeof(bnx2_rv2p_proc2), &text);
+ if (rc < 0)
goto init_cpu_err;
+ load_rv2p_fw(bp, text, rc /* == len */, RV2P_PROC2);
+ vfree(text);
- load_rv2p_fw(bp, text, text_len, RV2P_PROC2);
-
/* Initialize the RX Processor. */
cpu_reg.mode = BNX2_RXP_CPU_MODE;
cpu_reg.mode_value_halt = BNX2_RXP_CPU_MODE_SOFT_HALT;
@@ -3115,7 +3071,6 @@
goto init_cpu_err;
}
init_cpu_err:
- bnx2_gunzip_end(bp);
return rc;
}
--- linux-2.6.23-rc6.org/drivers/net/bnx2.h Tue Sep 11 22:33:54 2007
+++ linux-2.6.23-rc6.gunzip/drivers/net/bnx2.h Tue Sep 18 23:27:07 2007
@@ -6679,9 +6679,6 @@
u32 flash_size;
int status_stats_size;
-
- struct z_stream_s *strm;
- void *gunzip_buf;
};
static u32 bnx2_reg_rd_ind(struct bnx2 *bp, u32 offset);
@@ -6739,7 +6736,7 @@
const u32 text_addr;
const u32 text_len;
const u32 text_index;
- u32 *text;
+/* u32 *text;*/
u8 *gz_text;
const u32 gz_text_len;
--- linux-2.6.23-rc6.org/drivers/net/bnx2_fw.h Mon Jul 9 00:32:17 2007
+++ linux-2.6.23-rc6.gunzip/drivers/net/bnx2_fw.h Tue Sep 18 23:38:47 2007
@@ -15,7 +15,9 @@
*/
static u8 bnx2_COM_b06FwText[] = {
- 0x1f, 0x8b, 0x08, 0x00, 0x45, 0x30, 0xe7, 0x45, 0x00, 0x03, 0xdc, 0x5a,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x00, 0x45, 0x30, 0xe7, 0x45, 0x00, 0x03, */
+ 0xdc, 0x5a,
0x6b, 0x6c, 0x1c, 0xd7, 0x75, 0x3e, 0x33, 0x3b, 0x4b, 0xae, 0xc8, 0x15,
0x35, 0xa2, 0xc6, 0xf4, 0x5a, 0xa2, 0xed, 0x5d, 0x72, 0x28, 0x12, 0x96,
0xec, 0x6e, 0x68, 0xda, 0x62, 0x8c, 0x8d, 0xb4, 0xd9, 0xa5, 0x0c, 0xa1,
@@ -1085,8 +1087,10 @@
};
static u8 bnx2_RXP_b06FwText[] = {
- 0x1f, 0x8b, 0x08, 0x08, 0xcb, 0xa3, 0x46, 0x45, 0x00, 0x03, 0x74, 0x65,
- 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, 0xec, 0x5c, 0x6f, 0x6c,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x08, 0xcb, 0xa3, 0x46, 0x45, 0x00, 0x03, 0x74, 0x65,
+ 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, */
+ 0xec, 0x5c, 0x6f, 0x6c,
0x1c, 0xc7, 0x75, 0x7f, 0x3b, 0xbb, 0xa4, 0x4e, 0xd4, 0x91, 0x5c, 0x1e,
0x4f, 0xf4, 0x49, 0x66, 0x94, 0x5d, 0x71, 0x25, 0x5e, 0x2d, 0xc6, 0x5d,
0x31, 0x57, 0x9b, 0x08, 0xce, 0xf1, 0x79, 0xef, 0x64, 0xb1, 0x86, 0x0a,
@@ -1798,8 +1802,10 @@
};
static u8 bnx2_rv2p_proc1[] = {
- 0x1f, 0x8b, 0x08, 0x08, 0x5e, 0xd0, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
- 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, 0xc5, 0x56, 0xcf, 0x6b,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x08, 0x5e, 0xd0, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
+ 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, */
+ 0xc5, 0x56, 0xcf, 0x6b,
0x13, 0x51, 0x10, 0x9e, 0xec, 0x6e, 0xb2, 0xdb, 0x74, 0xbb, 0x1b, 0x2b,
0xda, 0xa0, 0xb1, 0x8d, 0x51, 0x6a, 0x7f, 0xa4, 0xb4, 0x11, 0x0f, 0x82,
0x42, 0x25, 0x3d, 0x04, 0x54, 0x44, 0x7a, 0x28, 0x22, 0x82, 0x36, 0x8a,
@@ -1877,8 +1883,10 @@
0x12, 0x3d, 0x80, 0x0b, 0x00, 0x00, 0x00 };
static u8 bnx2_rv2p_proc2[] = {
- 0x1f, 0x8b, 0x08, 0x08, 0x7e, 0xd1, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
- 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, 0xcd, 0x58, 0x5b, 0x6c,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x08, 0x7e, 0xd1, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
+ 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, */
+ 0xcd, 0x58, 0x5b, 0x6c,
0x54, 0x55, 0x14, 0x3d, 0xf3, 0xe8, 0xcc, 0x9d, 0xe9, 0xed, 0x9d, 0xf2,
0xb2, 0x03, 0xad, 0x08, 0xe5, 0xd1, 0x56, 0x29, 0xe8, 0x54, 0xab, 0x18,
0x15, 0x2c, 0x5a, 0x8c, 0x26, 0x68, 0xf0, 0xf9, 0x63, 0x14, 0x04, 0xda,
@@ -2057,8 +2065,10 @@
0x17, 0x00, 0x00, 0x00 };
static u8 bnx2_TPAT_b06FwText[] = {
- 0x1f, 0x8b, 0x08, 0x08, 0x47, 0xd2, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
- 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, 0xc5, 0x57, 0x4d, 0x68,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x08, 0x47, 0xd2, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
+ 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, */
+ 0xc5, 0x57, 0x4d, 0x68,
0x1c, 0xe7, 0x19, 0x7e, 0xe7, 0x77, 0x47, 0x62, 0x25, 0x8d, 0x93, 0x3d,
0xac, 0x5d, 0xa5, 0x99, 0x91, 0x46, 0x3f, 0x54, 0x26, 0x9e, 0x84, 0xa5,
0x56, 0x61, 0x20, 0xe3, 0x99, 0x95, 0x2c, 0x0c, 0x05, 0x07, 0x42, 0x08,
@@ -2290,8 +2300,10 @@
};
static u8 bnx2_TXP_b06FwText[] = {
- 0x1f, 0x8b, 0x08, 0x08, 0x21, 0xd3, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
- 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, 0xed, 0x5c, 0x6d, 0x6c,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x08, 0x21, 0xd3, 0x41, 0x44, 0x00, 0x03, 0x74, 0x65,
+ 0x73, 0x74, 0x31, 0x2e, 0x62, 0x69, 0x6e, 0x00, */
+ 0xed, 0x5c, 0x6d, 0x6c,
0x1b, 0xf7, 0x79, 0x7f, 0xee, 0x85, 0xd2, 0x51, 0x96, 0xe9, 0x93, 0xc2,
0x78, 0x6c, 0xc0, 0xa6, 0x77, 0xd6, 0x51, 0x66, 0x20, 0xb5, 0xa0, 0x05,
0x36, 0x55, 0x87, 0x43, 0x73, 0x3e, 0x52, 0x2f, 0x4e, 0x5c, 0x57, 0x71,
--- linux-2.6.23-rc6.org/drivers/net/bnx2_fw2.h Mon Jul 9 00:32:17 2007
+++ linux-2.6.23-rc6.gunzip/drivers/net/bnx2_fw2.h Tue Sep 18 23:37:41 2007
@@ -15,7 +15,9 @@
*/
static u8 bnx2_COM_b09FwText[] = {
- 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, 0xdc, 0x5b,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, */
+ 0xdc, 0x5b,
0x6d, 0x70, 0x5c, 0xd5, 0x79, 0x7e, 0xef, 0xd9, 0xbb, 0xf2, 0x5a, 0x92,
0xe5, 0x6b, 0x79, 0x23, 0x16, 0x4b, 0xc0, 0xae, 0x75, 0x6d, 0x69, 0xb0,
0x43, 0x16, 0xa1, 0x80, 0x9a, 0xd9, 0xc0, 0xb2, 0x2b, 0x33, 0x9e, 0x0c,
@@ -1083,7 +1085,9 @@
};
static u8 bnx2_CP_b09FwText[] = {
- 0x1f, 0x8b, 0x08, 0x00, 0x0f, 0x34, 0xe7, 0x45, 0x00, 0x03, 0xbd, 0x7d,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x00, 0x0f, 0x34, 0xe7, 0x45, 0x00, 0x03, */
+ 0xbd, 0x7d,
0x0d, 0x74, 0x5c, 0x57, 0x7d, 0xe7, 0xff, 0xdd, 0x19, 0x49, 0x63, 0x59,
0x96, 0x9f, 0xe5, 0x89, 0x32, 0x51, 0x84, 0x3d, 0x23, 0x3d, 0xd9, 0x22,
0x12, 0xe1, 0xc5, 0x11, 0xac, 0xda, 0x2a, 0xe9, 0x30, 0x92, 0x3f, 0x12,
@@ -2279,7 +2283,9 @@
};
static u8 bnx2_RXP_b09FwText[] = {
- 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, 0xec, 0x5c,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, */
+ 0xec, 0x5c,
0x5d, 0x6c, 0x1c, 0xd7, 0x75, 0x3e, 0xf3, 0x43, 0x6a, 0x49, 0xf1, 0x67,
0xb8, 0x5c, 0xb1, 0x2b, 0x99, 0x96, 0x77, 0xc9, 0x91, 0xc8, 0x58, 0x8a,
0x31, 0xa2, 0x09, 0x5b, 0x48, 0x17, 0xf6, 0x76, 0x76, 0x25, 0xb1, 0xb1,
@@ -2988,7 +2994,9 @@
};
static u8 bnx2_TPAT_b09FwText[] = {
- 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, 0xcd, 0x58,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, */
+ 0xcd, 0x58,
0x5d, 0x68, 0x1c, 0xd7, 0x15, 0x3e, 0xf3, 0xb7, 0x3b, 0x52, 0x24, 0xeb,
0x5a, 0xd9, 0xa6, 0xeb, 0xa0, 0x34, 0x33, 0xda, 0x91, 0xac, 0x22, 0x13,
0x4f, 0x9d, 0x25, 0x16, 0x65, 0x21, 0x93, 0xd9, 0x91, 0xac, 0x98, 0x3c,
@@ -3279,7 +3287,9 @@
};
static u8 bnx2_TXP_b09FwText[] = {
- 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, 0xcd, 0x7c,
+ 0x00, 0x80, 0x00, 0x00, /* unpack buf size = 0x8000 */
+/* 0x1f, 0x8b, 0x08, 0x00, 0x0e, 0x34, 0xe7, 0x45, 0x00, 0x03, */
+ 0xcd, 0x7c,
0x6f, 0x70, 0x5b, 0xd7, 0x95, 0xdf, 0x79, 0xef, 0x81, 0x24, 0x48, 0xd1,
0xd4, 0x13, 0x17, 0x56, 0x60, 0x87, 0x71, 0x00, 0xf1, 0x81, 0x66, 0x42,
0xae, 0x04, 0x2b, 0x4c, 0xc2, 0x6d, 0xd1, 0xf8, 0x05, 0x00, 0x29, 0x48,
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Patrick McHardy @ 2007-09-19 8:27 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Thomas Gleixner, Oliver Hartkopp,
Oliver Hartkopp
In-Reply-To: <ygffy1bzn4c.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
>
>>>+HLIST_HEAD(rx_dev_list);
>>
>>
>>Same here (static).
>
>
> Can't be static since it's used in proc.c. But __read_mostly might
> make sense.
>
> What exactly is the effect of __read_mostly? Is that in a separate
> ELF section? Where is that finally located?
Its a seperate section to prevent false sharing.
>
>
>>>+ if (ret == -ENOSYS)
>>>+ printk(KERN_INFO "can: request_module(%s) not"
>>>+ " implemented.\n", module_name);
>>>+ else if (ret)
>>>+ printk(KERN_ERR "can: request_module(%s) failed\n",
>>>+ module_name);
>>
>>
>>Both of these printks seem to be user-triggerable, so they should
>>be rate-limited (or maybe get removed completely/changed to DBG).
>
>
> Hm, I don't think DBG() would be right here, since the messages show
> problems in the installation to the admin. OTOH, I see that a user
> can flood the log by opening sockets with invalid proto numbers. Rate
> limiting might solve this, or we should print the message only once
> per proto number. I will think about this.
IMO this is a perfectly normal condition (not finding a module).
Especially the !KMOD case is hardly an error.
>>>+ /* check for success and correct type */
>>>+ cp = proto_tab[protocol];
>>
>>
>>What prevents the module from getting unloaded again (and using
>>a stale pointer)?
>
>
> When the module is unloaded it calls can_proto_unregister() which
> clears the pointer. Do you see a race condition here?
Yes, you do request_module, load the module, get the cp pointer
from proto_tab, the module is unloaded again. cp points to
stable memory. Using module references would fix this.
>>>+ if (!(skb->dev->flags & IFF_LOOPBACK)) {
>>>+ /*
>>>+ * If the interface is not capable to do loopback
>>>+ * itself, we do it here.
>>>+ */
>>>+ struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
>>>+
>>>+ if (!newskb) {
>>>+ kfree_skb(skb);
>>>+ return -ENOMEM;
>>>+ }
>>>+
>>>+ newskb->sk = skb->sk;
>>>+ newskb->ip_summed = CHECKSUM_UNNECESSARY;
>>>+ newskb->pkt_type = PACKET_BROADCAST;
>>>+ netif_rx(newskb);
>>
>>
>>So the intention here is to send the packet to the non-loopback device
>>and manually loop it, which means sending it twice?
>
>
> CAN is a broadcast message network, so every frame should be (usually)
> sent to all receivers, on remote hosts and to all local sockets. If
> the driver for the interface is not able to loop back the frame for
> local delivery, the can_send() function will do this as a fallback.
> For real CAN devices it is preferred that the driver does loopback.
> For vcan it makes no difference where loopback is done. The module
> paramenter for vcan is therefore only useful to test and debug the CAN
> core module. It is nothing a normal user will ever use.
Thanks for the explanation.
>>>+static struct dev_rcv_lists *find_dev_rcv_lists(struct net_device *dev)
>>>+{
>>>+ struct dev_rcv_lists *d;
>>>+ struct hlist_node *n;
>>>+
>>>+ ....
>>>+
>>>+ hlist_for_each_entry(d, n, &rx_dev_list, list) {
>>
>>
>>On the receive path you use RCU, so this should be
>>hlist_for_each_entry_rcu(), no? The bottem half disabling during
>>addition/removal also seems unnecessary, but I might be missing
>>something.
>
>
> find_dev_rcv_lists() is called in one place from can_rcv() with RCU
> lock held, as you write. The other two calls to find_dev_rcv_lists()
> are from can_rx_register/unregister() functions which change the
> receive lists. Therefore, we can't only use RCU but need protection
> against simultanous writes. We do this with the spin_lock_bh(). The
> _bh variant, because can_rcv() runs in interrupt and we need to block
> that. I thought this is pretty standard.
>
> I'll check this again tomorrow, but I have put much time in these
> locking issues already, changed it quite a few times and hoped to have
> got it right finally.
I'm not saying you should use *only* RCU, you need the lock
for additions/removal of course, but since the receive path
doesn't take that lock and relies on RCU, you need to use
the _rcu list walking variant to avoid races with concurrent
list changes.
>>>+ case NETDEV_REGISTER:
>>>+
>>>+ /*
>>>+ * create new dev_rcv_lists for this device
>>>+ *
>>>+ * N.B. zeroing the struct is the correct initialization
>>>+ * for the embedded hlist_head structs.
>>>+ * Another list type, e.g. list_head, would require
>>>+ * explicit initialization.
>>>+ */
>>>+
>>>+ DBG("creating new dev_rcv_lists for %s\n", dev->name);
>>>+
>>>+ d = kzalloc(sizeof(*d),
>>>+ in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
>>
>>
>>netdevice registration should never happen from interrupt handlers.
>
>
> Hm, I seem to remember we had such an occurance with hot-pluggable
> devices, i.e. USB. But I may be wrong. In what context is
> NETDEV_REGISTER called for e.g. USB devices? Can we safely write
> just GFP_KERNEL here?
Yes. register_netdevice() takes the rtnl mutex, so it can only
be used in process context.
>>>+ stattimer.expires = jiffies + HZ;
>>
>>round_jiffies?
>
>
> Yes. We don't depend on exact times relative to module load time, but
> we would like to have the timer expirations 1 second apart. But we
> would still get this with round_jiffies(), right?
I don't think you will get *exactly* one second, but you also have
no guarantee for that now.
>>>+ * proc read functions
>>>+ *
>>>+ * From known use-cases we expect about 10 entries in a receive list to be
>>>+ * printed in the proc_fs. So PAGE_SIZE is definitely enough space here.
>>
>>
>>Would be nicer to use seq_file (for all the proc stuff).
>
>
> That has already been on my TODO list. There was some problem which I
> don't remember ATM, which is why I dropped it temporarily. Now on my
> TODO list again.
Thanks :)
^ permalink raw reply
* Re: [PATCH 3/7] CAN: Add raw protocol
From: Patrick McHardy @ 2007-09-19 8:34 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Thomas Gleixner, Oliver Hartkopp,
Oliver Hartkopp
In-Reply-To: <ygfbqbzzls5.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
>
>
>>>+config CAN_RAW_USER
>>>+ bool "Allow non-root users to access Raw CAN Protocol sockets"
>>>+ depends on CAN_RAW
>>
>>Would it be much more trouble for userspace to use capabilities for
>>this? This would allow userspace to always know what to expect, I
>>don't think distributions will enable this option (which might again
>>not matter since they're probably rarely used in cars :)).
>
>
> First, it's not only used in cars but also in other embedded and
> automation contexts :-)
>
> In fact, we already check capabilities in af_can.c:can_create() like
> this
>
> if (cp->capability >= 0 && !capable(cp->capability))
> return -EPERM;
>
> Each protocol implementation can set cp->capability to -1 so that all
> users can open sockets without any restriction or to some capability,
> typically CAP_NET_RAW. In raw.c it is done so
>
> #ifdef CONFIG_CAN_RAW_USER
> #define RAW_CAP (-1)
> #else
> #define RAW_CAP CAP_NET_RAW
> #endif
>
> I also didn't love this configure option very much when we added it.
> But in embedded systems it is often not much of a problem to let
> anybody access raw sockets, since there are no "normal" users. This
> is the reason for the configure option. I haven't yet looked into
> capabilities and their inheritance between process in detail. Would
> it be easy to let all user space run with CAP_NET_RAW? What if some
> process calls setuid() or execve()s a set-uid program? Will
> capabilities be retained?
If its in the inheritable set, I believe it is retained. I mainly
don't like it because I believe permission checks shouldn't depend
on config option, this makes it harder for userspace to know what
to expect. But keep it if you must.
>>>+static int raw_notifier(struct notifier_block *nb,
>>>+ unsigned long msg, void *data)
>>>+{
>>>+ struct net_device *dev = (struct net_device *)data;
>>>+ struct raw_sock *ro = container_of(nb, struct raw_sock, notifier);
>>>+ struct sock *sk = &ro->sk;
>>>+
>>>+ DBG("msg %ld for dev %p (%s idx %d) sk %p ro->ifindex %d\n",
>>>+ msg, dev, dev->name, dev->ifindex, sk, ro->ifindex);
>>>+
>>>+ if (dev->nd_net != &init_net)
>>>+ return NOTIFY_DONE;
>>>+
>>>+ if (dev->type != ARPHRD_CAN)
>>>+ return NOTIFY_DONE;
>>>+
>>>+ if (ro->ifindex != dev->ifindex)
>>>+ return NOTIFY_DONE;
>>
>>
>>Wouldn't that be a BUG()?
>
>
> Would it? I think there is only one netdev_chain, not one per
> device. I.e. our raw_notifier() gets all events on any netdevice, not
> only the ones we're interested in, for example also eth0. And I think
> we should silently ignore these events by returning NOTIFY_DONE. Am I
> missing something here?
No, I misunderstood the code.
^ permalink raw reply
* Re: [PATCH 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
From: James Chapman @ 2007-09-19 8:43 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Michal Ostrowski, Paul Mackerras,
Toralf Förster, netdev
In-Reply-To: <20070919012529.GA15046@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Sep 18, 2007 at 09:19:33PM +0100, James Chapman wrote:
>> This one causes my test system to lock up. I'll investigate. Please
>> don't apply this patch for now.
>
> Sorry, I added a double-free on the skb after ip_queue_xmit.
> Please try this one instead.
>
> - /* Free the original skb */
> - kfree_skb(skb);
> -
> return 1;
>
> -discard:
> - /* Free the new skb. Caller will free original skb. */
> - if (skb2 != skb)
> - kfree_skb(skb2);
> abort:
> - return 0;
> + /* Free the original skb */
> + kfree_skb(skb);
> + return 1;
> }
Shouldn't this return 0 in the error case and without the kfree_skb()?
This lets ppp requeue the skb.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Patrick McHardy @ 2007-09-19 8:41 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Thomas Gleixner, Oliver Hartkopp,
Oliver Hartkopp
In-Reply-To: <ygf7imnzk60.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
>
>
>>>+static int loopback; /* loopback testing. Default: 0 (Off) */
>>>+module_param(loopback, int, S_IRUGO);
>>>+MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");
>>
>>
>>I would still prefer to have this on a per-device level configured
>>through netlink, but since we currently don't support specifying
>>flags for new devices anyways, I won't argue about it anymore
>>(OTOH, if you'd agree I could send a patch to add this feature
>>to the rtnl_link API).
>
>
> Hm, somehow this topic comes up again and again. I think there is
> some misunderstanding about loopback in general and vcan, but I must
> admit that our documentation until recently didn't describe this good
> enough. In fact, I think we also got better understanding from this
> discussion and trying to explain this.
>
> vcan is *not* a special loopback device like lo and it is not needed
> to use PF_CAN. Every CAN device driver should preferably loop back
> frames sent by dev->hard_start_xmit() to netif_rx(). Since this is
> unusual for netdevice drivers, the CAN core can do this itself as a
> fallback for drivers that don't loopback.
I understood that from Oliver's explanations.
> For vcan it makes no difference whether loopback is done in the vcan
> driver or in the CAN core. No user will ever have to use this module
> parameter. Having a driver which can show both driver behaviors is
> however useful for debugging our own code, to check whether the CAN
> core does the right thing in both cases.
>
> vcan is not a loopback device but a null device which simply discards
> all sent frames since there is no hardware to send the frame to. Like
> other CAN drivers it can loop back the frame to the CAN core, but this
> is not different from other CAN drivers.
>
> It can be useful to have several vcan null devices so that different
> apps can talk to each other through different interfaces.
My opinion is simply that stuff like that shouldn't be configured
through module parameters, but as I said, I don't want to get into
this discussion again, its not a big deal if you insist on keeping
it.
> Now I think we should consider removing the loopback code from
> can_send() and demand from each CAN driver that it *has to* implement
> this itself.
Really? I don't know about any other drivers, but it seems to make
sense to me to handle this in the core instead of reimplementing
it in every driver.
>
>
>>>+
>>>+struct vcan_priv {
>>>+ struct net_device *dev;
>>>+ struct list_head list;
>>>+};
>>
>>
>>This is not needed anymore. The rtnl_link_unregister function calls
>>the ->dellink function for each device of this type. Check out the
>>current dummy.c driver.
>
>
> OK.
>
>
>>>+ if (atomic_read(&skb->users) != 1) {
>>>+ struct sk_buff *old_skb = skb;
>>>+
>>>+ skb = skb_clone(old_skb, GFP_ATOMIC);
>>>+ DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
>>>+ "using new skbuff %p\n",
>>>+ dev->name, __FUNCTION__, old_skb, skb);
>>>+ kfree_skb(old_skb);
>>
>>skb_share_check()?
>
>
> New to me. I read that skb_share_check() decrements the refcount so I
> am not sure it is we want. Will take a look tomorrow.
It kfree_skb's the old skb, just as you do above.
>
>
>>>+ /* receive with packet counting */
>>>+ skb->sk = srcsk;
>>
>>
>>Where is the socket used and what makes sure it still exists?
>
>
> This socket pointer is used when the loopback frame is processed in
> raw_rcv, only to compare it to the receiving socket to determine if
> this frame was sent by the receiving socket itself. The srcsk is only
> compared, not dereferenced.
Thanks for the explanation, that should be fine.
^ permalink raw reply
* Re: [PATCH 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
From: Herbert Xu @ 2007-09-19 8:51 UTC (permalink / raw)
To: James Chapman
Cc: David S. Miller, Michal Ostrowski, Paul Mackerras,
Toralf Förster, netdev
In-Reply-To: <46F0E145.4020501@katalix.com>
On Wed, Sep 19, 2007 at 09:43:49AM +0100, James Chapman wrote:
>
> >-discard:
> >- /* Free the new skb. Caller will free original skb. */
> >- if (skb2 != skb)
> >- kfree_skb(skb2);
> > abort:
> >- return 0;
> >+ /* Free the original skb */
> >+ kfree_skb(skb);
> >+ return 1;
> > }
>
> Shouldn't this return 0 in the error case and without the kfree_skb()?
> This lets ppp requeue the skb.
No. As I described in the changelog, the return value of 0
is only meaningful for ppp_async and ppp_sync. Returning 0
means that you're congested, not that there has been a
temporary error and the packet should be retried.
Retransmission should be left to the higher protocols.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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: [PATCH] phy: export phy_mii_ioctl
From: Pedro Luis D. L. @ 2007-09-19 8:54 UTC (permalink / raw)
To: Jon Smirl, Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709181229m4afe7ecr56e2411f52a84232@mail.gmail.com>
Hello Jon,
I´m also working with a Phytec pcm030, but I can´t get it booted...
Which kernel are you using?
I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released.
The base kernel I´m using is 2.6.22.6 from kernel.org.
Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time.
Bytes transferred = 5091 (13e3 hex)
## Booting image at 00500000 ...
Image Name: Linux-2.6.22.6
Created: 2007-09-19 8:53:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1196911 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
(No more output and boot is halted)
Are you using any other patch for the platform or any other kernel, because I tried to apply these patches to a 2.6.20 kernel and are not successful.
Bests,
Pedro.
> Date: Tue, 18 Sep 2007 15:29:09 -0400> From: jonsmirl@gmail.com
> To: domen@coderock.org> Subject: Re: [PATCH] phy: export phy_mii_ioctl
> CC: netdev@vger.kernel.org; linuxppc-embedded@ozlabs.org
>> On 9/18/07, Domen Puncer wrote:
>> More testing and getting it to work properly on Phytec pcm030 would
>> be great.>> Do we want to do anything about this?
>> [ 1.569657] net eth0: attached phy 0 to driver Generic PHY
> [ 2.576013] Sending DHCP requests .PHY: f0003000:00 - Link is Up
> - 100/Full> [ 4.612000] ., OK
> [ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my
> address is 192.168.1.5
>> What is happening is the printk for "PHY: f0003000:00 - Link is Up
> - 100/Full" is done in an interrupt and it comes in the middle of the> kernel doing DHCP and printing ... without a CR.
>> Two possible solutions, get rid of the link-up message or wait in in
> the initial driver load until the link is up. Or we could leave it the
> way it is, but some people may report this as a bug.
>>> --> Jon Smirl> jonsmirl@gmail.com
> _______________________________________________
> Linuxppc-embedded mailing list> Linuxppc-embedded@ozlabs.org> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Busca desde cualquier página Web con una protección excepcional. Consigue la Barra de herramientas de Windows Live hoy mismo y GRATUITAMENTE.
http://www.toolbar.live.com
^ permalink raw reply
* RE: [PATCH] phy: export phy_mii_ioctl
From: Pedro Luis D. L. @ 2007-09-19 8:54 UTC (permalink / raw)
To: Jon Smirl, Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709181229m4afe7ecr56e2411f52a84232@mail.gmail.com>
Hello Jon,
I´m also working with a Phytec pcm030, but I can´t get it booted...
Which kernel are you using?
I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released.
The base kernel I´m using is 2.6.22.6 from kernel.org.
Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time.
Bytes transferred = 5091 (13e3 hex)
## Booting image at 00500000 ...
Image Name: Linux-2.6.22.6
Created: 2007-09-19 8:53:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1196911 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
(No more output and boot is halted)
Are you using any other patch for the platform or any other kernel, because I tried to apply these patches to a 2.6.20 kernel and are not successful.
Bests,
Pedro.
> Date: Tue, 18 Sep 2007 15:29:09 -0400> From: jonsmirl@gmail.com
> To: domen@coderock.org> Subject: Re: [PATCH] phy: export phy_mii_ioctl
> CC: netdev@vger.kernel.org; linuxppc-embedded@ozlabs.org
>> On 9/18/07, Domen Puncer wrote:
>> More testing and getting it to work properly on Phytec pcm030 would
>> be great.>> Do we want to do anything about this?
>> [ 1.569657] net eth0: attached phy 0 to driver Generic PHY
> [ 2.576013] Sending DHCP requests .PHY: f0003000:00 - Link is Up
> - 100/Full> [ 4.612000] ., OK
> [ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my
> address is 192.168.1.5
>> What is happening is the printk for "PHY: f0003000:00 - Link is Up
> - 100/Full" is done in an interrupt and it comes in the middle of the> kernel doing DHCP and printing ... without a CR.
>> Two possible solutions, get rid of the link-up message or wait in in
> the initial driver load until the link is up. Or we could leave it the
> way it is, but some people may report this as a bug.
>>> --> Jon Smirl> jonsmirl@gmail.com
> _______________________________________________
> Linuxppc-embedded mailing list> Linuxppc-embedded@ozlabs.org> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Busca desde cualquier página Web con una protección excepcional. Consigue la Barra de herramientas de Windows Live hoy mismo y GRATUITAMENTE.
http://www.toolbar.live.com
^ 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