* Re: [PATCH (for some future time)] drivers/net: Convert unbounded kzalloc calls to kcalloc
From: Luciano Coelho @ 2010-08-12 6:48 UTC (permalink / raw)
To: ext Joe Perches; +Cc: netdev, linux-wireless, linux-kernel@vger.kernel.org
In-Reply-To: <1281546168.3976.39.camel@Joe-Laptop.home>
On Wed, 2010-08-11 at 19:02 +0200, ext Joe Perches wrote:
> These changes may be slightly safer in some instances.
>
> There are other kzalloc calls with a multiply, but those
> calls are typically "small fixed #" * sizeof(some pointer)"
> and those are not converted.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
[...]
> drivers/net/wireless/wl12xx/wl1271_scan.c | 2 +-
[...]
> diff --git a/drivers/net/wireless/wl12xx/wl1271_scan.c b/drivers/net/wireless/wl12xx/wl1271_scan.c
> index fec43ee..30dc100 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_scan.c
> +++ b/drivers/net/wireless/wl12xx/wl1271_scan.c
> @@ -248,7 +248,7 @@ int wl1271_scan(struct wl1271 *wl, const u8 *ssid, size_t ssid_len,
>
> wl->scan.req = req;
>
> - wl->scan.scanned_ch = kzalloc(req->n_channels *
> + wl->scan.scanned_ch = kcalloc(req->n_channels,
> sizeof(*wl->scan.scanned_ch),
> GFP_KERNEL);
> wl1271_scan_stm(wl);
For the wl1271 part:
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 1/1] netfilter: xt_condition: add condition target support
From: Luciano Coelho @ 2010-08-12 6:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, kaber, jengelh, sameo, janne.ylalehto
In-Reply-To: <1281595021-24310-1-git-send-email-luciano.coelho@nokia.com>
This patch implements a condition target to the xt_condition module,
which let's the user set netfilter rules that change the variables
used by the condition match. Originally, the condition match only
allowed the variable to be changed via procfs. This new target makes
it easy to change the condition value depending on the rules set.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
include/linux/netfilter/xt_condition.h | 13 ++-
net/netfilter/Kconfig | 19 ++--
net/netfilter/Makefile | 2 +-
net/netfilter/xt_condition.c | 194 +++++++++++++++++++++++---------
4 files changed, 165 insertions(+), 63 deletions(-)
diff --git a/include/linux/netfilter/xt_condition.h b/include/linux/netfilter/xt_condition.h
index c4fe899..946d43a 100644
--- a/include/linux/netfilter/xt_condition.h
+++ b/include/linux/netfilter/xt_condition.h
@@ -3,8 +3,10 @@
#include <linux/types.h>
+#define XT_CONDITION_MAX_NAME_SIZE 27
+
struct xt_condition_mtinfo {
- char name[27];
+ char name[XT_CONDITION_MAX_NAME_SIZE];
__u8 invert;
__u32 value;
@@ -12,4 +14,13 @@ struct xt_condition_mtinfo {
void *condvar __attribute__((aligned(8)));
};
+struct condition_tginfo {
+ char name[XT_CONDITION_MAX_NAME_SIZE];
+ __u8 padding;
+ __u32 value;
+
+ /* Used internally by the kernel */
+ void *condvar __attribute__((aligned(8)));
+};
+
#endif /* _XT_CONDITION_H */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 5044dd6..d9a17eb 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -310,6 +310,17 @@ config NETFILTER_XT_MARK
"Use netfilter MARK value as routing key") and can also be used by
other subsystems to change their behavior.
+config NETFILTER_XT_CONDITION
+ tristate '"condition" match and target support'
+ depends on NETFILTER_ADVANCED
+ depends on PROC_FS
+ ---help---
+ This option adds the "CONDITION" target and "condition" match.
+
+ It allows you to match rules against condition variables
+ stored in the /proc/net/nf_condition directory. It also allows
+ you to set the variables using the target.
+
config NETFILTER_XT_CONNMARK
tristate 'ctmark target and match support'
depends on NF_CONNTRACK
@@ -621,14 +632,6 @@ config NETFILTER_XT_MATCH_COMMENT
If you want to compile it as a module, say M here and read
<file:Documentation/kbuild/modules.txt>. If unsure, say `N'.
-config NETFILTER_XT_MATCH_CONDITION
- tristate '"condition" match support'
- depends on NETFILTER_ADVANCED
- depends on PROC_FS
- ---help---
- This option allows you to match firewall rules against condition
- variables stored in the /proc/net/nf_condition directory.
-
config NETFILTER_XT_MATCH_CONNBYTES
tristate '"connbytes" per-connection counter match support'
depends on NF_CONNTRACK
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index bbf72bb..146a05f 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_NETFILTER_XTABLES) += x_tables.o xt_tcpudp.o
# combos
obj-$(CONFIG_NETFILTER_XT_MARK) += xt_mark.o
obj-$(CONFIG_NETFILTER_XT_CONNMARK) += xt_connmark.o
+obj-$(CONFIG_NETFILTER_XT_CONDITION) += xt_condition.o
# targets
obj-$(CONFIG_NETFILTER_XT_TARGET_CHECKSUM) += xt_CHECKSUM.o
@@ -67,7 +68,6 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_IDLETIMER) += xt_IDLETIMER.o
# matches
obj-$(CONFIG_NETFILTER_XT_MATCH_CLUSTER) += xt_cluster.o
obj-$(CONFIG_NETFILTER_XT_MATCH_COMMENT) += xt_comment.o
-obj-$(CONFIG_NETFILTER_XT_MATCH_CONDITION) += xt_condition.o
obj-$(CONFIG_NETFILTER_XT_MATCH_CONNBYTES) += xt_connbytes.o
obj-$(CONFIG_NETFILTER_XT_MATCH_CONNLIMIT) += xt_connlimit.o
obj-$(CONFIG_NETFILTER_XT_MATCH_CONNTRACK) += xt_conntrack.o
diff --git a/net/netfilter/xt_condition.c b/net/netfilter/xt_condition.c
index cc9ada9..06205aa 100644
--- a/net/netfilter/xt_condition.c
+++ b/net/netfilter/xt_condition.c
@@ -2,15 +2,20 @@
* "condition" match extension for Xtables
*
* Description: This module allows firewall rules to match using
- * condition variables available through procfs.
+ * condition variables available through procfs. It also allows
+ * target rules to set the condition variable.
*
* Authors:
* Stephane Ouellette <ouellettes [at] videotron ca>, 2002-10-22
* Massimiliano Hofer <max [at] nucleus it>, 2006-05-15
+ * Luciano Coelho <luciano.coelho@nokia.com>, 2010-08-11
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License; either version 2
* or 3 of the License, as published by the Free Software Foundation.
+ *
+ * Portion Copyright 2010 Nokia Corporation and/or its subsidiary(-ies).
+ * File modified on 2010-08-11.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/kernel.h>
@@ -33,7 +38,8 @@ static unsigned int condition_gid_perms = 0;
MODULE_AUTHOR("Stephane Ouellette <ouellettes@videotron.ca>");
MODULE_AUTHOR("Massimiliano Hofer <max@nucleus.it>");
MODULE_AUTHOR("Jan Engelhardt <jengelh@medozas.de>");
-MODULE_DESCRIPTION("Allows rules to match against condition variables");
+MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
+MODULE_DESCRIPTION("Allows rules to set and match condition variables");
MODULE_LICENSE("GPL");
module_param(condition_list_perms, uint, S_IRUSR | S_IWUSR);
MODULE_PARM_DESC(condition_list_perms, "default permissions on /proc/net/nf_condition/* files");
@@ -104,29 +110,11 @@ static int condition_proc_write(struct file *file, const char __user *input,
return length;
}
-static bool
-condition_mt(const struct sk_buff *skb, struct xt_action_param *par)
-{
- const struct xt_condition_mtinfo *info = par->matchinfo;
- const struct condition_variable *var = info->condvar;
-
- return (var->value == info->value) ^ info->invert;
-}
-
-static int condition_mt_check(const struct xt_mtchk_param *par)
+static struct
+condition_variable *xt_condition_insert(const char *name,
+ struct condition_net *cond_net)
{
- struct xt_condition_mtinfo *info = par->matchinfo;
struct condition_variable *var;
- struct condition_net *cond_net = condition_pernet(par->net);
-
- /* Forbid certain names */
- if (*info->name == '\0' || *info->name == '.' ||
- info->name[sizeof(info->name)-1] != '\0' ||
- memchr(info->name, '/', sizeof(info->name)) != NULL) {
- pr_info("name not allowed or too long: \"%.*s\"\n",
- (unsigned int)sizeof(info->name), info->name);
- return -EINVAL;
- }
/*
* Let's acquire the lock, check for the condition and add it
@@ -134,29 +122,24 @@ static int condition_mt_check(const struct xt_mtchk_param *par)
*/
mutex_lock(&proc_lock);
list_for_each_entry(var, &cond_net->list, list) {
- if (strcmp(info->name, var->status_proc->name) == 0) {
+ if (strcmp(name, var->status_proc->name) == 0) {
++var->refcount;
- mutex_unlock(&proc_lock);
- info->condvar = var;
- return 0;
+ goto out;
}
}
/* At this point, we need to allocate a new condition variable. */
var = kmalloc(sizeof(struct condition_variable), GFP_KERNEL);
- if (var == NULL) {
- mutex_unlock(&proc_lock);
- return -ENOMEM;
- }
+ if (var == NULL)
+ goto out;
/* Create the condition variable's proc file entry. */
- var->status_proc = create_proc_entry(info->name,
- condition_list_perms,
+ var->status_proc = create_proc_entry(name, condition_list_perms,
cond_net->proc_dir);
if (var->status_proc == NULL) {
kfree(var);
- mutex_unlock(&proc_lock);
- return -ENOMEM;
+ var = NULL;
+ goto out;
}
var->refcount = 1;
@@ -167,17 +150,14 @@ static int condition_mt_check(const struct xt_mtchk_param *par)
var->status_proc->uid = condition_uid_perms;
var->status_proc->gid = condition_gid_perms;
list_add(&var->list, &cond_net->list);
+out:
mutex_unlock(&proc_lock);
- info->condvar = var;
- return 0;
+ return var;
}
-static void condition_mt_destroy(const struct xt_mtdtor_param *par)
+static void xt_condition_put(struct condition_variable *var,
+ struct condition_net *cond_net)
{
- const struct xt_condition_mtinfo *info = par->matchinfo;
- struct condition_variable *var = info->condvar;
- struct condition_net *cond_net = condition_pernet(par->net);
-
mutex_lock(&proc_lock);
if (--var->refcount == 0) {
list_del(&var->list);
@@ -192,6 +172,106 @@ static void condition_mt_destroy(const struct xt_mtdtor_param *par)
mutex_unlock(&proc_lock);
}
+static bool
+condition_mt(const struct sk_buff *skb, struct xt_action_param *par)
+{
+ const struct xt_condition_mtinfo *info = par->matchinfo;
+ const struct condition_variable *var = info->condvar;
+
+ return (var->value == info->value) ^ info->invert;
+}
+
+static int condition_mt_check(const struct xt_mtchk_param *par)
+{
+ struct xt_condition_mtinfo *info = par->matchinfo;
+ struct condition_variable *var;
+ struct condition_net *cond_net = condition_pernet(par->net);
+
+ /* Forbid certain names */
+ if (*info->name == '\0' || *info->name == '.' ||
+ info->name[sizeof(info->name)-1] != '\0' ||
+ memchr(info->name, '/', sizeof(info->name)) != NULL) {
+ pr_info("name not allowed or too long: \"%.*s\"\n",
+ (unsigned int)sizeof(info->name), info->name);
+ return -EINVAL;
+ }
+
+ var = xt_condition_insert(info->name, cond_net);
+ if (var == NULL)
+ return -ENOMEM;
+
+ info->condvar = var;
+ return 0;
+}
+
+static void condition_mt_destroy(const struct xt_mtdtor_param *par)
+{
+ const struct xt_condition_mtinfo *info = par->matchinfo;
+ struct condition_net *cond_net = condition_pernet(par->net);
+
+ xt_condition_put(info->condvar, cond_net);
+}
+
+static unsigned int condition_tg_target(struct sk_buff *skb,
+ const struct xt_action_param *par)
+{
+ const struct condition_tginfo *info = par->targinfo;
+ struct condition_variable *var = info->condvar;
+
+ pr_debug("setting condition %s, value %d\n",
+ info->name, info->value);
+
+ var->value = info->value;
+
+ return XT_CONTINUE;
+}
+
+static int condition_tg_checkentry(const struct xt_tgchk_param *par)
+{
+ struct condition_tginfo *info = par->targinfo;
+ struct condition_variable *var;
+ struct condition_net *cond_net = condition_pernet(par->net);
+
+ pr_debug("checkentry %s\n", info->name);
+
+ /* Forbid certain names */
+ if (*info->name == '\0' || *info->name == '.' ||
+ info->name[sizeof(info->name)-1] != '\0' ||
+ memchr(info->name, '/', sizeof(info->name)) != NULL) {
+ pr_info("name not allowed or too long: \"%.*s\"\n",
+ (unsigned int)sizeof(info->name), info->name);
+ return -EINVAL;
+ }
+
+ var = xt_condition_insert(info->name, cond_net);
+ if (var == NULL)
+ return -ENOMEM;
+
+ info->condvar = var;
+ return 0;
+}
+
+static void condition_tg_destroy(const struct xt_tgdtor_param *par)
+{
+ const struct condition_tginfo *info = par->targinfo;
+ struct condition_net *cond_net = condition_pernet(par->net);
+
+ pr_debug("destroy %s\n", info->name);
+
+ xt_condition_put(info->condvar, cond_net);
+}
+
+static struct xt_target condition_tg_reg __read_mostly = {
+ .name = "CONDITION",
+ .revision = 0,
+ .family = NFPROTO_UNSPEC,
+ .target = condition_tg_target,
+ .targetsize = sizeof(struct condition_tginfo),
+ .checkentry = condition_tg_checkentry,
+ .destroy = condition_tg_destroy,
+ .me = THIS_MODULE,
+};
+
static struct xt_match condition_mt_reg __read_mostly = {
.name = "condition",
.revision = 2,
@@ -205,7 +285,7 @@ static struct xt_match condition_mt_reg __read_mostly = {
static const char *const dir_name = "nf_condition";
-static int __net_init condnet_mt_init(struct net *net)
+static int __net_init condnet_init(struct net *net)
{
struct condition_net *cond_net = condition_pernet(net);
@@ -216,7 +296,7 @@ static int __net_init condnet_mt_init(struct net *net)
return (cond_net->proc_dir == NULL) ? -EACCES : 0;
}
-static void __net_exit condnet_mt_exit(struct net *net)
+static void __net_exit condnet_exit(struct net *net)
{
struct condition_net *cond_net = condition_pernet(net);
struct condition_variable *var, *tmp;
@@ -234,14 +314,14 @@ static void __net_exit condnet_mt_exit(struct net *net)
remove_proc_entry(dir_name, net->proc_net);
}
-static struct pernet_operations condition_mt_netops = {
- .init = condnet_mt_init,
- .exit = condnet_mt_exit,
+static struct pernet_operations condition_netops = {
+ .init = condnet_init,
+ .exit = condnet_exit,
.id = &condition_net_id,
.size = sizeof(struct condition_net),
};
-static int __init condition_mt_init(void)
+static int __init condition_init(void)
{
int ret;
@@ -250,8 +330,15 @@ static int __init condition_mt_init(void)
if (ret < 0)
return ret;
- ret = register_pernet_subsys(&condition_mt_netops);
+ ret = xt_register_target(&condition_tg_reg);
+ if (ret < 0) {
+ xt_unregister_match(&condition_mt_reg);
+ return ret;
+ }
+
+ ret = register_pernet_subsys(&condition_netops);
if (ret < 0) {
+ xt_unregister_target(&condition_tg_reg);
xt_unregister_match(&condition_mt_reg);
return ret;
}
@@ -259,11 +346,12 @@ static int __init condition_mt_init(void)
return 0;
}
-static void __exit condition_mt_exit(void)
+static void __exit condition_exit(void)
{
- unregister_pernet_subsys(&condition_mt_netops);
+ unregister_pernet_subsys(&condition_netops);
xt_unregister_match(&condition_mt_reg);
+ xt_unregister_target(&condition_tg_reg);
}
-module_init(condition_mt_init);
-module_exit(condition_mt_exit);
+module_init(condition_init);
+module_exit(condition_exit);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/1] netfilter: xt_condition: add condition target
From: Luciano Coelho @ 2010-08-12 6:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, kaber, jengelh, sameo, janne.ylalehto
Hello,
So here's my patch to include the condition target in the existing condition
module. This patch is supposed to be applied on top of the previous
xt_condition patches I submitted and is intended for 2.6.37 (I'll resend all
the 3 patches when the next tree starts accepting patches again).
One thing that came to my mind was whether it would make sense to rename this
match/target combo to "variable" instead of "condition". To me it makes more
sense to call it variable than condition, since I have changed the value from
boolean to u32. On the other hand, it could become very confusing because it
used to be called condition in its xtables-addons days...
Your comments are appreciated!
Cheers,
Luca.
Luciano Coelho (1):
netfilter: xt_condition: add condition target support
include/linux/netfilter/xt_condition.h | 13 ++-
net/netfilter/Kconfig | 19 ++--
net/netfilter/Makefile | 2 +-
net/netfilter/xt_condition.c | 194 +++++++++++++++++++++++---------
4 files changed, 165 insertions(+), 63 deletions(-)
^ permalink raw reply
* RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Wang, Qi @ 2010-08-12 6:29 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Greg KH, Daniel Baluta, Masayuki Ohtak, meego-dev@meego.com,
Wolfgang Grandegger, socketcan-core@lists.berlios.de,
netdev@vger.kernel.org, Khor, Andrew Chih Howe,
arjan@linux.intel.com, Wang, Yong Y
In-Reply-To: <4C6393F0.5090005@hartkopp.net>
> -----Original Message-----
> From: Oliver Hartkopp [mailto:socketcan@hartkopp.net]
> Sent: Thursday, August 12, 2010 2:26 PM
> To: Wang, Qi
> Cc: Greg KH; Daniel Baluta; Masayuki Ohtak; meego-dev@meego.com;
> Wolfgang Grandegger; socketcan-core@lists.berlios.de;
> netdev@vger.kernel.org; Khor, Andrew Chih Howe; arjan@linux.intel.com;
> Wang, Yong Y
> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
>
> On 12.08.2010 04:04, Greg KH wrote:
> > On Thu, Aug 12, 2010 at 09:42:27AM +0800, Wang, Qi wrote:
>
> >>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> >> Just take a look at kfifo.h. This structure has been changed. I
> >> remembered there was a spin_lock from kfifo previously. Currently it's
> >> been removed, good.
> >> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
> use this structure and APIs?
> >>
> >> Daniel,
> >>
> >> We're anxious to integrate those codes now. Perhaps it'll take us
> >> quite a long time to use kfifo. How about implementing it with the
> >> next version?
> >
> > What do you mean by this? Code isn't merged into the tree unless it is
> > correct. Please fix this now, it's not that big of a deal.
> >
>
> Hello Qi,
>
> i generally wonder what this FIFO is used for??
>
> For me it looks like a artifact from a former chardev implementation, as
> several other code sniplets do (see comments from Wolfgang and Marc).
>
> The network driver model is used for CAN drivers and therefore all the
> infrastructure for queueing inbound and outbound network traffic should be
> used from the Kernel like all other CAN drivers and all other ethernet drivers
> do.
>
> Additionally there is a powerful infrastructure to support the special
> functions of CAN netdevices (like setting of bittimings, listen-only modes, or
> to produce CAN driver states etc.), that's part of the CAN drivers in
> drivers/net/can/ since it has gone mainline.
>
> CAN netdevices are intentionally dumb (like the original ethernet adapters).
> This allows a simple driver interface between the kernel and the hardware
> driver, e.g. for queueing CAN frames. CAN drivers don't use any hardware
> rx-filtering(!) due to multiuser requirements and it's a vital requirement
> that the frames are not re-ordered on sending (by the 'some magic' CAN
> controller dealing with CAN-ID priorities, e.g. see tx-path in the MSCAN driver).
>
> From my perspective about 70% of your code is obsolete, as you implemented
> tricky details (like FIFOs, bittiming tables or magic filter handlings),
> that's not needed at all.
>
> Please take a look at the SJA1000 driver (for a low complex CAN controller) or
> at the TI driver (for a higher complex CAN controller) how these drivers
> handle the specialties of each hardware. And read some documentation in
> Documentation/networking/can.txt to get an impression about the concepts of
> the CAN implementation in the Linux Kernel and the CAN netdevices.
>
> I strongly assume that your driver would be about 30 kBytes of code fitting
> into a single c-file like the ti_hecc.c does. And that's definitely easier for
> us to review and easier for you to maintain in the future ...
>
> Thanks & best regards,
> Oliver
Thank you for your commits.
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Oliver Hartkopp @ 2010-08-12 6:25 UTC (permalink / raw)
To: Wang, Qi
Cc: Khor, Andrew Chih Howe,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Greg KH,
Wang, Yong Y, Masayuki Ohtak,
meego-dev-WXzIur8shnEAvxtiuMwx3w@public.gmane.org,
arjan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Wolfgang Grandegger
In-Reply-To: <20100812020414.GD14121-l3A5Bk7waGM@public.gmane.org>
On 12.08.2010 04:04, Greg KH wrote:
> On Thu, Aug 12, 2010 at 09:42:27AM +0800, Wang, Qi wrote:
>>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
>> Just take a look at kfifo.h. This structure has been changed. I
>> remembered there was a spin_lock from kfifo previously. Currently it's
>> been removed, good.
>> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>>
>> Daniel,
>>
>> We're anxious to integrate those codes now. Perhaps it'll take us
>> quite a long time to use kfifo. How about implementing it with the
>> next version?
>
> What do you mean by this? Code isn't merged into the tree unless it is
> correct. Please fix this now, it's not that big of a deal.
>
Hello Qi,
i generally wonder what this FIFO is used for??
For me it looks like a artifact from a former chardev implementation, as
several other code sniplets do (see comments from Wolfgang and Marc).
The network driver model is used for CAN drivers and therefore all the
infrastructure for queueing inbound and outbound network traffic should be
used from the Kernel like all other CAN drivers and all other ethernet drivers do.
Additionally there is a powerful infrastructure to support the special
functions of CAN netdevices (like setting of bittimings, listen-only modes, or
to produce CAN driver states etc.), that's part of the CAN drivers in
drivers/net/can/ since it has gone mainline.
CAN netdevices are intentionally dumb (like the original ethernet adapters).
This allows a simple driver interface between the kernel and the hardware
driver, e.g. for queueing CAN frames. CAN drivers don't use any hardware
rx-filtering(!) due to multiuser requirements and it's a vital requirement
that the frames are not re-ordered on sending (by the 'some magic' CAN
controller dealing with CAN-ID priorities, e.g. see tx-path in the MSCAN driver).
>From my perspective about 70% of your code is obsolete, as you implemented
tricky details (like FIFOs, bittiming tables or magic filter handlings),
that's not needed at all.
Please take a look at the SJA1000 driver (for a low complex CAN controller) or
at the TI driver (for a higher complex CAN controller) how these drivers
handle the specialties of each hardware. And read some documentation in
Documentation/networking/can.txt to get an impression about the concepts of
the CAN implementation in the Linux Kernel and the CAN netdevices.
I strongly assume that your driver would be about 30 kBytes of code fitting
into a single c-file like the ti_hecc.c does. And that's definitely easier for
us to review and easier for you to maintain in the future ...
Thanks & best regards,
Oliver
^ permalink raw reply
* Re: [PATCH] netpoll: use non-BH variant of RCU
From: David Miller @ 2010-08-12 6:16 UTC (permalink / raw)
To: linville; +Cc: herbert, paulmck, netdev
In-Reply-To: <20100811153736.GA31577@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 11 Aug 2010 11:37:36 -0400
> On Wed, Aug 11, 2010 at 07:27:06AM -0400, Herbert Xu wrote:
>> On Wed, Aug 11, 2010 at 07:03:30AM -0400, Herbert Xu wrote:
>> >
>> > To use rcu_read_lock safely we'd also need to add do synchronize_rcu
>> > in addition of synchronize_rcu_bh, right Paul?
>> >
>> > Of course as we were doing this unsafely prior to my patch anyway
>> > I'm also fine with just reverting it.
>>
>> Actually, we could just disable IRQs for stable. How about this
>> patch (untested)?
>>
>> netpoll: Disable IRQ around RCU dereference in netpoll_rx
>>
>> We cannot use rcu_dereference_bh safely in netpoll_rx as we may
>> be called with IRQs disabled. We could however simply disable
>> IRQs as that too causes BH to be disabled and is safe in either
>> case.
>>
>> Thanks to John Linville for discovering this bug and providing
>> a patch.
>>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> This also seems to work for me.
I'll queue up this variant for -stable.
And we'll go with making use of Paul's new RCU irqsoff interface
approach for Linus's tree.
Thanks.
^ permalink raw reply
* Re: [PATCH] netpoll: use non-BH variant of RCU
From: David Miller @ 2010-08-12 6:09 UTC (permalink / raw)
To: paulmck; +Cc: herbert, linville, netdev
In-Reply-To: <20100811220047.GH2516@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Wed, 11 Aug 2010 15:00:47 -0700
> @@ -113,6 +113,12 @@ int rcu_my_thread_group_empty(void)
> return thread_group_empty(current);
> }
> EXPORT_SYMBOL_GPL(rcu_my_thread_group_empty);
> +
> +void rcu_read_unlock_bh_irqsoff_check(void)
> +{
> + WARN_ON_ONCE(in_irq() || irqs_disabled());
> +}
> +EXPORT_SYMBOL_GPL(rcu_read_unlock_bh_irqsoff_check);
> #endif /* #ifdef CONFIG_PROVE_RCU */
Is this WARN_ON_ONCE() test inverted? It seems to be called where we
"should be" in an IRQ or have IRQs disabled.
^ permalink raw reply
* Re: [PATCH -next] phylib: available for any speed ethernet
From: David Miller @ 2010-08-12 6:04 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100811162657.cfb767a7.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 11 Aug 2010 16:26:57 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Several gigabit network drivers (SB1250_MAC, TIGON3, FSL, GIANFAR,
> UCC_GETH, MV643XX_ETH, XILINX_LL_TEMAC, S6GMAC, STMMAC_ETH, PASEMI_MAC,
> and OCTEON_ETHERNET) select PHYLIB. These drivers are not under
> NET_ETHERNET (10/100 mbit), so this warning is generated (long, irrelevant
> parts are omitted):
>
> warning: (NET_DSA && NET && EXPERIMENTAL && NET_ETHERNET && !S390 || ... || SB1250_MAC && NETDEVICES && NETDEV_1000 && SIBYTE_SB1xxx_SOC || TIGON3 && NETDEVICES && NETDEV_1000 && PCI || FSL_PQ_MDIO && NETDEVICES && NETDEV_1000 && FSL_SOC || GIANFAR && NETDEVICES && NETDEV_1000 && FSL_SOC || UCC_GETH && NETDEVICES && NETDEV_1000 && QUICC_ENGINE || MV643XX_ETH && NETDEVICES && NETDEV_1000 && (MV64X60 || PPC32 || PLAT_ORION) || XILINX_LL_TEMAC && NETDEVICES && NETDEV_1000 && (PPC || MICROBLAZE) || S6GMAC && NETDEVICES && NETDEV_1000 && XTENSA_VARIANT_S6000 || STMMAC_ETH && NETDEV_1000 && NETDEVICES && CPU_SUBTYPE_ST40 || PASEMI_MAC && NETDEVICES && NETDEV_10000 && PPC_PASEMI && PCI || OCTEON_ETHERNET && STAGING && !STAGING_EXCLUDE_BUILD && CPU_CAVIUM_OCTEON) selects PHYLIB which has unmet d
irect dependencies (!S390 && NET_ETHERNET)
>
> PHYLIB is used by non-10/100 mbit ethernet drivers, so change the dependencies
> to be NETDEVICES instead of NET_ETHERNET.
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Fair enough, applied, thanks Randy.
^ permalink raw reply
* Re: sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully
From: Maciej Żenczykowski @ 2010-08-12 5:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Hemminger, Linux NetDev
In-Reply-To: <20100811215932.26414efe@s6510>
Here's lspci (it's an otherwise stock MacBook Pro 4,1 with a
non-standard wireless atheros mini-pci nic, replacing the std
broadcom.)
$ lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI
Express Root Port (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 1 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 3 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface
Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
SATA IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce
8600M GT] (rev a1)
0b:00.0 Network controller: Atheros Communications Inc. AR928X
Wireless Network Adapter (PCI-Express) (rev 01)
0c:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8058
PCI-E Gigabit Ethernet Controller (rev 13)
0d:03.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b
Link Layer Controller (rev 02)
(more verbose lspci included in bugzilla entry)
At least one other person has seen this on a desktop non-mac machine
(see bugzilla) entry.
What would you like from dmesg?
Is the following enough?
Aug 9 12:09:11 nike kernel: sky2: driver version 1.27
Aug 9 12:09:11 nike kernel: sky2 0000:0c:00.0: PCI INT A -> GSI 17
(level, low) -> IRQ 17
Aug 9 12:09:11 nike kernel: sky2 0000:0c:00.0: Yukon-2 EC Ultra chip revision 3
Aug 9 12:09:11 nike kernel: sky2 0000:0c:00.0: eth0: addr 00:1f:5b:xx:xx:xx
...
Aug 9 12:09:22 nike kernel: sky2 0000:0c:00.0: eth0: enabling interface
Aug 9 12:09:22 nike kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
...
Aug 9 12:09:25 nike kernel: sky2 0000:0c:00.0: eth0: Link is up at
1000 Mbps, full duplex, flow control rx
Aug 9 12:09:25 nike kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
...
Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
status 0x5d60100 length 2982
Aug 11 16:21:27 nike kernel: eth0: hw csum failure.
...
I'd just like to point out that this has happened something like 5
times in the past 30 days on a machine which is on 24/7 with wired
ethernet plugged in nearly 100% of the time.
^ permalink raw reply
* Re: [PATCH NEXT 0/8]qlcnic: enhancement and fixes
From: David Miller @ 2010-08-12 5:23 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80F86E68D08@MNEXMB2.qlogic.org>
From: Amit Salecha <amit.salecha@qlogic.com>
Date: Wed, 11 Aug 2010 22:41:39 -0500
>>> Series of 8 patches to fix minor bugs and to add statistics support.
>
> Don't apply these patches, I will send you updated one.
Ok.
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Daniel Baluta @ 2010-08-12 5:17 UTC (permalink / raw)
To: Wang, Qi
Cc: Khor, Andrew Chih Howe,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gregkh-l3A5Bk7waGM@public.gmane.org, Wang, Yong Y, Masayuki Ohtak,
meego-dev-WXzIur8shnEAvxtiuMwx3w@public.gmane.org,
arjan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Wolfgang Grandegger
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26EB-QQHDSDV1ERZpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
>> 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> No.
I want in the near future to write a Socket-CAN based driver for CAN EP80579.
As far as I've seen from your implementation there are a lot of
similarities between these
two drivers. Perhaps we can built a core part to both benefit from it.
>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> Just take a look at kfifo.h. This structure has been changed. I remembered there was a spin_lock from kfifo previously. Currently it's been removed, good.
Inded, the kfifo infrastructure has suffered great reworkings in the
latest kernel versions, but this
is not an excuse to not use it.
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>
> Daniel,
>
> We're anxious to integrate those codes now. Perhaps it'll take us quite a long time to use kfifo. How about implementing it with the next version?
In my opinion, as it looks now your code will never be accepted by the
SocketCAN maintainers.
thanks,
Daniel.
^ permalink raw reply
* RE: [PATCH NEXT 0/8]qlcnic: enhancement and fixes
From: Amit Salecha @ 2010-08-12 3:41 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, Ameen Rahman
In-Reply-To: <1281528329-8812-1-git-send-email-amit.salecha@qlogic.com>
>> Series of 8 patches to fix minor bugs and to add statistics support.
Don't apply these patches, I will send you updated one.
-----Original Message-----
From: Amit Kumar Salecha [mailto:amit.salecha@qlogic.com]
Sent: Wednesday, August 11, 2010 5:35 PM
To: davem@davemloft.net
Cc: netdev@vger.kernel.org; Ameen Rahman
Subject: [PATCH NEXT 0/8]qlcnic: enhancement and fixes
Hi
Series of 8 patches to fix minor bugs and to add statistics
support. Please apply them on net-next branch.
-Amit
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Masayuki Ohtake @ 2010-08-12 2:39 UTC (permalink / raw)
To: Daniel Baluta, Wang, Qi
Cc: Wang, Yong Y, arjan, gregkh, Khor, Andrew Chih Howe, netdev,
socketcan-core, Wolfgang Grandegger, meego-dev
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26EB@shsmsx501.ccr.corp.intel.com>
Hi Qi-san
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
Thank you for your answer.
We will start doing the above next week.
Thanks, Ohtake
----- Original Message -----
From: "Wang, Qi" <qi.wang@intel.com>
To: "Daniel Baluta" <daniel.baluta@gmail.com>; "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>
Cc: <meego-dev@meego.com>; "Wolfgang Grandegger" <wg@grandegger.com>; <socketcan-core@lists.berlios.de>;
<netdev@vger.kernel.org>; "Khor, Andrew Chih Howe" <andrew.chih.howe.khor@intel.com>; <gregkh@suse.de>;
<arjan@linux.intel.com>; "Wang, Yong Y" <yong.y.wang@intel.com>
Sent: Thursday, August 12, 2010 10:42 AM
Subject: RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> > -----Original Message-----
> > From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> > Sent: Wednesday, August 11, 2010 6:37 PM
> > To: Masayuki Ohtak
> > Cc: meego-dev@meego.com; Wolfgang Grandegger;
> > socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew Chih
> > Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> >
> > Hi,
> >
> > 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > > CAN driver of Topcliff PCH
> > >
> > > Topcliff PCH is the platform controller hub that is going to be used in
> > > Intel's upcoming general embedded platform. All IO peripherals in
> > > Topcliff PCH are actually devices sitting on AMBA bus.
> > > Topcliff PCH has CAN I/F. This driver enables CAN function.
> > >
> > > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
> >
> > I have a few questions:
> >
> > 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> No.
> > 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> Just take a look at kfifo.h. This structure has been changed. I remembered there was a spin_lock from kfifo
previously. Currently it's been removed, good.
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>
> Daniel,
>
> We're anxious to integrate those codes now. Perhaps it'll take us quite a long time to use kfifo. How about
implementing it with the next version?
>
> Best Regards,
> Qi.
>
> > 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
> Currently this datasheet isn't open.
> >
> > thanks,
> > Daniel.
> >
> > [1] http://www.intel.com/design/intarch/ep80579/sw_tools.htm
> > [2] http://lxr.linux.no/#linux+v2.6.35/kernel/kfifo.c
>
^ permalink raw reply
* RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Wang, Qi @ 2010-08-12 2:13 UTC (permalink / raw)
To: Khor, Andrew Chih Howe, Masayuki Ohtak
Cc: Daniel Baluta, meego-dev@meego.com, Wolfgang Grandegger,
socketcan-core@lists.berlios.de, netdev@vger.kernel.org,
arjan@linux.intel.com, Wang, Yong Y, Greg KH
In-Reply-To: <20100812020414.GD14121@suse.de>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, August 12, 2010 10:04 AM
> To: Wang, Qi
> Cc: Daniel Baluta; Masayuki Ohtak; meego-dev@meego.com; Wolfgang
> Grandegger; socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor,
> Andrew Chih Howe; arjan@linux.intel.com; Wang, Yong Y
> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
>
> On Thu, Aug 12, 2010 at 09:42:27AM +0800, Wang, Qi wrote:
> > > -----Original Message-----
> > > From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> > > Sent: Wednesday, August 11, 2010 6:37 PM
> > > To: Masayuki Ohtak
> > > Cc: meego-dev@meego.com; Wolfgang Grandegger;
> > > socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew
> Chih
> > > Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> > > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to
> 2.6.35
> > >
> > > Hi,
> > >
> > > 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > > > CAN driver of Topcliff PCH
> > > >
> > > > Topcliff PCH is the platform controller hub that is going to be used in
> > > > Intel's upcoming general embedded platform. All IO peripherals in
> > > > Topcliff PCH are actually devices sitting on AMBA bus.
> > > > Topcliff PCH has CAN I/F. This driver enables CAN function.
> > > >
> > > > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
> > >
> > > I have a few questions:
> > >
> > > 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> > No.
> > > 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> > Just take a look at kfifo.h. This structure has been changed. I
> > remembered there was a spin_lock from kfifo previously. Currently it's
> > been removed, good.
> > OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
> use this structure and APIs?
> >
> > Daniel,
> >
> > We're anxious to integrate those codes now. Perhaps it'll take us
> > quite a long time to use kfifo. How about implementing it with the
> > next version?
>
> What do you mean by this? Code isn't merged into the tree unless it is
> correct. Please fix this now, it's not that big of a deal.
Hi Ohtak-san,
Would you please use kfifo structure? It'll take you some time to study it, but it's a good structure.
>
> > > 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
> > Currently this datasheet isn't open.
>
> Even under NDA? The Linux foundation offers a service to allow
> developers access to data sheets so that they can do kernel development
> and code review.
Hi Andrew,
Can ECG share those datasheet to the open source? Only with that datasheet, the upstream can review the source codes from OKI.
Best Regards,
Qi
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Greg KH @ 2010-08-12 2:04 UTC (permalink / raw)
To: Wang, Qi
Cc: Daniel Baluta, Masayuki Ohtak, meego-dev@meego.com,
Wolfgang Grandegger, socketcan-core@lists.berlios.de,
netdev@vger.kernel.org, Khor, Andrew Chih Howe,
arjan@linux.intel.com, Wang, Yong Y
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26EB@shsmsx501.ccr.corp.intel.com>
On Thu, Aug 12, 2010 at 09:42:27AM +0800, Wang, Qi wrote:
> > -----Original Message-----
> > From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> > Sent: Wednesday, August 11, 2010 6:37 PM
> > To: Masayuki Ohtak
> > Cc: meego-dev@meego.com; Wolfgang Grandegger;
> > socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew Chih
> > Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> >
> > Hi,
> >
> > 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > > CAN driver of Topcliff PCH
> > >
> > > Topcliff PCH is the platform controller hub that is going to be used in
> > > Intel's upcoming general embedded platform. All IO peripherals in
> > > Topcliff PCH are actually devices sitting on AMBA bus.
> > > Topcliff PCH has CAN I/F. This driver enables CAN function.
> > >
> > > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
> >
> > I have a few questions:
> >
> > 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> No.
> > 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> Just take a look at kfifo.h. This structure has been changed. I
> remembered there was a spin_lock from kfifo previously. Currently it's
> been removed, good.
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>
> Daniel,
>
> We're anxious to integrate those codes now. Perhaps it'll take us
> quite a long time to use kfifo. How about implementing it with the
> next version?
What do you mean by this? Code isn't merged into the tree unless it is
correct. Please fix this now, it's not that big of a deal.
> > 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
> Currently this datasheet isn't open.
Even under NDA? The Linux foundation offers a service to allow
developers access to data sheets so that they can do kernel development
and code review.
thanks,
greg k-h
^ permalink raw reply
* Re: sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully
From: Stephen Hemminger @ 2010-08-12 1:59 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Stephen Hemminger, Linux NetDev
In-Reply-To: <AANLkTinMK7n51v4uBPYChYV7KOye8WEvdCFDanfd2mVL@mail.gmail.com>
On Wed, 11 Aug 2010 17:48:59 -0700
Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
> [See https://bugzilla.redhat.com/show_bug.cgi?id=592398 ]
>
> Latest tested kernel (from koji for Fedora 13):
>
> 2.6.34.3-35.rc1.fc13.x86_64
>
> Basically occasionally, but possibly more and more often with recent
> kernels (I think .33 and .34 are worse then .32) the sky2 driver locks
> up.
>
> During this time the nic functions like a DSL line with a 95% drop
> rate. ie. sometimes something does get through, but mostly it's dead.
> "ip link set eth0 down && ip link set eth0 up" is enough to fix it.
>
> Here's the initial occurrence of this problem on the above kernel.
>
> Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
> status 0x5d60100 length 2982
> Aug 11 16:21:27 nike kernel: eth0: hw csum failure.
> Aug 11 16:21:27 nike kernel: Pid: 0, comm: swapper Not tainted
> 2.6.34.3-35.rc1.fc13.x86_64 #1
> Aug 11 16:21:27 nike kernel: Call Trace:
> Aug 11 16:21:27 nike kernel: <IRQ> [<ffffffff813a5c5b>]
> netdev_rx_csum_fault+0x3b/0x3f
> Aug 11 16:21:27 nike kernel: [<ffffffff8139f909>]
> __skb_checksum_complete_head+0x51/0x65
> Aug 11 16:21:27 nike kernel: [<ffffffff8139f92e>]
> __skb_checksum_complete+0x11/0x13
> Aug 11 16:21:27 nike kernel: [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
> Aug 11 16:21:27 nike kernel: [<ffffffff813cc791>] udp_error+0x130/0x18a
> Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
> Aug 11 16:21:27 nike kernel: [<ffffffff81037c67>] ? activate_task+0x2f/0x37
> Aug 11 16:21:27 nike kernel: [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
> Aug 11 16:21:27 nike kernel: [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
> Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
> Aug 11 16:21:27 nike kernel: [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
> Aug 11 16:21:27 nike kernel: [<ffffffff813c4c56>] nf_iterate+0x46/0x89
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> Aug 11 16:21:27 nike kernel: [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
> Aug 11 16:21:27 nike kernel: [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
> Aug 11 16:21:27 nike kernel: [<ffffffff813d510b>] ip_rcv+0x256/0x283
> Aug 11 16:21:27 nike kernel: [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
> Aug 11 16:21:27 nike kernel: [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
> Aug 11 16:21:27 nike kernel: [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
> Aug 11 16:21:27 nike kernel: [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
> Aug 11 16:21:27 nike kernel: [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
> Aug 11 16:21:27 nike kernel: [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
> Aug 11 16:21:27 nike kernel: [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
> Aug 11 16:21:27 nike kernel: [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
> Aug 11 16:21:27 nike kernel: [<ffffffff8100c342>] do_softirq+0x46/0x83
> Aug 11 16:21:27 nike kernel: [<ffffffff810530b5>] irq_exit+0x3b/0x7d
> Aug 11 16:21:27 nike kernel: [<ffffffff81452434>] do_IRQ+0xac/0xc3
> Aug 11 16:21:27 nike kernel: [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
> Aug 11 16:21:27 nike kernel: <EOI> [<ffffffff8127ef7b>] ?
> acpi_idle_enter_bm+0x288/0x2bc
> Aug 11 16:21:27 nike kernel: [<ffffffff8127ef74>] ?
> acpi_idle_enter_bm+0x281/0x2bc
> Aug 11 16:21:27 nike kernel: [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
> Aug 11 16:21:27 nike kernel: [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
> Aug 11 16:21:27 nike kernel: [<ffffffff8144553e>] start_secondary+0x253/0x294
> Aug 11 16:21:34 nike kernel: eth0: hw csum failure.
> Aug 11 16:21:34 nike kernel: Pid: 0, comm: swapper Not tainted
> 2.6.34.3-35.rc1.fc13.x86_64 #1
> Aug 11 16:21:34 nike kernel: Call Trace:
> Aug 11 16:21:34 nike kernel: <IRQ> [<ffffffff813a5c5b>]
> netdev_rx_csum_fault+0x3b/0x3f
> Aug 11 16:21:34 nike kernel: [<ffffffff8139f909>]
> __skb_checksum_complete_head+0x51/0x65
> Aug 11 16:21:34 nike kernel: [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0
> ...
> etc, 700 messages over the course of the next hour (until I came back
> and ip link down/up fixed it).
>
> # cat /var/log/messages | egrep 'rx len'
> Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
> status 0x5d60100 length 2982
>
> (also seen on an older kernel [ 2.6.33.5-112.fc13.x86_64 ]:
> Jul 17 12:43:10 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 3018
> Jul 28 02:34:46 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 1642
> Jul 30 09:49:16 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 3018
> Jul 31 00:20:26 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 3018
> and kernels before that, including 2.6.32.12-115.fc12.x86_64, but I
> think I might have seen the problem even further back than 2.6.32).
>
> # cat /var/log/messages | egrep 'eth0: hw csum failure\.$' | wc -l
> 694
>
> The call stacks differ, here's the most common symbols with the number
> of times they occur
> (although this probably isn't particularly useful):
>
> # cat /var/log/messages | egrep ffffffff | sed -rn 's@^^Aug ..
> ..:..:.. nike kernel: @@p' | sort | uniq -c | egrep -v '^ [
> 1-9][0-9] '
> 602 <EOI> [<ffffffff8127ef7b>] ? acpi_idle_enter_bm+0x288/0x2bc
> 630 [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
> 694 [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
> 693 [<ffffffff8100c342>] do_softirq+0x46/0x83
> 273 [<ffffffff81010261>] ? sched_clock+0x9/0xd
> 105 [<ffffffff8101038f>] ? native_sched_clock+0x2d/0x5f
> 254 [<ffffffff810205a8>] ? lapic_next_event+0x1d/0x21
> 190 [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
> 285 [<ffffffff81037c67>] ? activate_task+0x2f/0x37
> 144 [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
> 693 [<ffffffff810530b5>] irq_exit+0x3b/0x7d
> 694 [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
> 103 [<ffffffff8106b281>] ? sched_clock_local+0x1c/0x82
> 693 [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
> 202 [<ffffffff8107148d>] ? clockevents_program_event+0x7a/0x83
> 255 [<ffffffff810725e5>] ? tick_dev_program_event+0x3c/0xfc
> 703 [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
> 348 [<ffffffff810fe9af>] ? virt_to_head_page+0xe/0x2f
> 528 [<ffffffff81216662>] ? __bitmap_weight+0x40/0x8f
> 602 [<ffffffff8127ef74>] ? acpi_idle_enter_bm+0x281/0x2bc
> 629 [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
> 115 [<ffffffff8139cffd>] ? __kfree_skb+0x7d/0x81
> 694 [<ffffffff8139f909>] __skb_checksum_complete_head+0x51/0x65
> 694 [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0x13
> 694 [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
> 694 [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
> 694 [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
> 694 [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
> 695 [<ffffffff813c4c56>] nf_iterate+0x46/0x89
> 695 [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
> 145 [<ffffffff813c4d20>] ? nf_hook_slow+0x87/0xcb
> 694 [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
> 690 [<ffffffff813cc791>] udp_error+0x130/0x18a
> 2083 [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> 163 [<ffffffff813d4c58>] ? ip_local_deliver_finish+0x0/0x1b3
> 694 [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
> 694 [<ffffffff813d510b>] ip_rcv+0x256/0x283
> 694 [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
> 694 [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
> 338 [<ffffffff81434d5a>] rest_init+0x7e/0x80
> 295 [<ffffffff8144553e>] start_secondary+0x253/0x294
> 151 [<ffffffff8144c8a6>] ? _raw_spin_unlock_bh+0x15/0x17
> 687 [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
> 687 [<ffffffff81452434>] do_IRQ+0xac/0xc3
> 338 [<ffffffff81bae2c8>] x86_64_start_reservations+0xb3/0xb7
> 338 [<ffffffff81bae3c4>] x86_64_start_kernel+0xf8/0x107
> 338 [<ffffffff81baee6f>] start_kernel+0x413/0x41e
> 694 [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
> 150 [<ffffffffa05850ea>] ? nf_nat_cleanup_conntrack+0x69/0x6d [nf_nat]
> 694 <IRQ> [<ffffffff813a5c5b>] netdev_rx_csum_fault+0x3b/0x3f
What is the dmesg and lspci info. Looks like a timing issue which
is unique to your machine/bus hardware combination. could
you just turn off hardware rx checksum (with ethtool).
^ permalink raw reply
* RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Wang, Qi @ 2010-08-12 1:42 UTC (permalink / raw)
To: Daniel Baluta, Masayuki Ohtak
Cc: meego-dev@meego.com, Wolfgang Grandegger,
socketcan-core@lists.berlios.de, netdev@vger.kernel.org,
Khor, Andrew Chih Howe, gregkh@suse.de, arjan@linux.intel.com,
Wang, Yong Y
In-Reply-To: <AANLkTinZ510_k2E5JFxa8jcuv8gRABFakyrcfzsg2vm1@mail.gmail.com>
> -----Original Message-----
> From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> Sent: Wednesday, August 11, 2010 6:37 PM
> To: Masayuki Ohtak
> Cc: meego-dev@meego.com; Wolfgang Grandegger;
> socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew Chih
> Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
>
> Hi,
>
> 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > CAN driver of Topcliff PCH
> >
> > Topcliff PCH is the platform controller hub that is going to be used in
> > Intel's upcoming general embedded platform. All IO peripherals in
> > Topcliff PCH are actually devices sitting on AMBA bus.
> > Topcliff PCH has CAN I/F. This driver enables CAN function.
> >
> > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
>
> I have a few questions:
>
> 1. Is your code based on Intel's CAN EP80579 ([1]) ?
No.
> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
Just take a look at kfifo.h. This structure has been changed. I remembered there was a spin_lock from kfifo previously. Currently it's been removed, good.
OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
Daniel,
We're anxious to integrate those codes now. Perhaps it'll take us quite a long time to use kfifo. How about implementing it with the next version?
Best Regards,
Qi.
> 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
Currently this datasheet isn't open.
>
> thanks,
> Daniel.
>
> [1] http://www.intel.com/design/intarch/ep80579/sw_tools.htm
> [2] http://lxr.linux.no/#linux+v2.6.35/kernel/kfifo.c
^ permalink raw reply
* sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully
From: Maciej Żenczykowski @ 2010-08-12 0:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux NetDev
[See https://bugzilla.redhat.com/show_bug.cgi?id=592398 ]
Latest tested kernel (from koji for Fedora 13):
2.6.34.3-35.rc1.fc13.x86_64
Basically occasionally, but possibly more and more often with recent
kernels (I think .33 and .34 are worse then .32) the sky2 driver locks
up.
During this time the nic functions like a DSL line with a 95% drop
rate. ie. sometimes something does get through, but mostly it's dead.
"ip link set eth0 down && ip link set eth0 up" is enough to fix it.
Here's the initial occurrence of this problem on the above kernel.
Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
status 0x5d60100 length 2982
Aug 11 16:21:27 nike kernel: eth0: hw csum failure.
Aug 11 16:21:27 nike kernel: Pid: 0, comm: swapper Not tainted
2.6.34.3-35.rc1.fc13.x86_64 #1
Aug 11 16:21:27 nike kernel: Call Trace:
Aug 11 16:21:27 nike kernel: <IRQ> [<ffffffff813a5c5b>]
netdev_rx_csum_fault+0x3b/0x3f
Aug 11 16:21:27 nike kernel: [<ffffffff8139f909>]
__skb_checksum_complete_head+0x51/0x65
Aug 11 16:21:27 nike kernel: [<ffffffff8139f92e>]
__skb_checksum_complete+0x11/0x13
Aug 11 16:21:27 nike kernel: [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
Aug 11 16:21:27 nike kernel: [<ffffffff813cc791>] udp_error+0x130/0x18a
Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
Aug 11 16:21:27 nike kernel: [<ffffffff81037c67>] ? activate_task+0x2f/0x37
Aug 11 16:21:27 nike kernel: [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
Aug 11 16:21:27 nike kernel: [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
Aug 11 16:21:27 nike kernel: [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
Aug 11 16:21:27 nike kernel: [<ffffffff813c4c56>] nf_iterate+0x46/0x89
Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
Aug 11 16:21:27 nike kernel: [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
Aug 11 16:21:27 nike kernel: [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
Aug 11 16:21:27 nike kernel: [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
Aug 11 16:21:27 nike kernel: [<ffffffff813d510b>] ip_rcv+0x256/0x283
Aug 11 16:21:27 nike kernel: [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
Aug 11 16:21:27 nike kernel: [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
Aug 11 16:21:27 nike kernel: [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
Aug 11 16:21:27 nike kernel: [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
Aug 11 16:21:27 nike kernel: [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
Aug 11 16:21:27 nike kernel: [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
Aug 11 16:21:27 nike kernel: [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
Aug 11 16:21:27 nike kernel: [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
Aug 11 16:21:27 nike kernel: [<ffffffff8100c342>] do_softirq+0x46/0x83
Aug 11 16:21:27 nike kernel: [<ffffffff810530b5>] irq_exit+0x3b/0x7d
Aug 11 16:21:27 nike kernel: [<ffffffff81452434>] do_IRQ+0xac/0xc3
Aug 11 16:21:27 nike kernel: [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
Aug 11 16:21:27 nike kernel: <EOI> [<ffffffff8127ef7b>] ?
acpi_idle_enter_bm+0x288/0x2bc
Aug 11 16:21:27 nike kernel: [<ffffffff8127ef74>] ?
acpi_idle_enter_bm+0x281/0x2bc
Aug 11 16:21:27 nike kernel: [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
Aug 11 16:21:27 nike kernel: [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
Aug 11 16:21:27 nike kernel: [<ffffffff8144553e>] start_secondary+0x253/0x294
Aug 11 16:21:34 nike kernel: eth0: hw csum failure.
Aug 11 16:21:34 nike kernel: Pid: 0, comm: swapper Not tainted
2.6.34.3-35.rc1.fc13.x86_64 #1
Aug 11 16:21:34 nike kernel: Call Trace:
Aug 11 16:21:34 nike kernel: <IRQ> [<ffffffff813a5c5b>]
netdev_rx_csum_fault+0x3b/0x3f
Aug 11 16:21:34 nike kernel: [<ffffffff8139f909>]
__skb_checksum_complete_head+0x51/0x65
Aug 11 16:21:34 nike kernel: [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0
...
etc, 700 messages over the course of the next hour (until I came back
and ip link down/up fixed it).
# cat /var/log/messages | egrep 'rx len'
Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
status 0x5d60100 length 2982
(also seen on an older kernel [ 2.6.33.5-112.fc13.x86_64 ]:
Jul 17 12:43:10 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 3018
Jul 28 02:34:46 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 1642
Jul 30 09:49:16 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 3018
Jul 31 00:20:26 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 3018
and kernels before that, including 2.6.32.12-115.fc12.x86_64, but I
think I might have seen the problem even further back than 2.6.32).
# cat /var/log/messages | egrep 'eth0: hw csum failure\.$' | wc -l
694
The call stacks differ, here's the most common symbols with the number
of times they occur
(although this probably isn't particularly useful):
# cat /var/log/messages | egrep ffffffff | sed -rn 's@^^Aug ..
..:..:.. nike kernel: @@p' | sort | uniq -c | egrep -v '^ [
1-9][0-9] '
602 <EOI> [<ffffffff8127ef7b>] ? acpi_idle_enter_bm+0x288/0x2bc
630 [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
694 [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
693 [<ffffffff8100c342>] do_softirq+0x46/0x83
273 [<ffffffff81010261>] ? sched_clock+0x9/0xd
105 [<ffffffff8101038f>] ? native_sched_clock+0x2d/0x5f
254 [<ffffffff810205a8>] ? lapic_next_event+0x1d/0x21
190 [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
285 [<ffffffff81037c67>] ? activate_task+0x2f/0x37
144 [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
693 [<ffffffff810530b5>] irq_exit+0x3b/0x7d
694 [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
103 [<ffffffff8106b281>] ? sched_clock_local+0x1c/0x82
693 [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
202 [<ffffffff8107148d>] ? clockevents_program_event+0x7a/0x83
255 [<ffffffff810725e5>] ? tick_dev_program_event+0x3c/0xfc
703 [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
348 [<ffffffff810fe9af>] ? virt_to_head_page+0xe/0x2f
528 [<ffffffff81216662>] ? __bitmap_weight+0x40/0x8f
602 [<ffffffff8127ef74>] ? acpi_idle_enter_bm+0x281/0x2bc
629 [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
115 [<ffffffff8139cffd>] ? __kfree_skb+0x7d/0x81
694 [<ffffffff8139f909>] __skb_checksum_complete_head+0x51/0x65
694 [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0x13
694 [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
694 [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
694 [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
694 [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
695 [<ffffffff813c4c56>] nf_iterate+0x46/0x89
695 [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
145 [<ffffffff813c4d20>] ? nf_hook_slow+0x87/0xcb
694 [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
690 [<ffffffff813cc791>] udp_error+0x130/0x18a
2083 [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
163 [<ffffffff813d4c58>] ? ip_local_deliver_finish+0x0/0x1b3
694 [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
694 [<ffffffff813d510b>] ip_rcv+0x256/0x283
694 [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
694 [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
338 [<ffffffff81434d5a>] rest_init+0x7e/0x80
295 [<ffffffff8144553e>] start_secondary+0x253/0x294
151 [<ffffffff8144c8a6>] ? _raw_spin_unlock_bh+0x15/0x17
687 [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
687 [<ffffffff81452434>] do_IRQ+0xac/0xc3
338 [<ffffffff81bae2c8>] x86_64_start_reservations+0xb3/0xb7
338 [<ffffffff81bae3c4>] x86_64_start_kernel+0xf8/0x107
338 [<ffffffff81baee6f>] start_kernel+0x413/0x41e
694 [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
150 [<ffffffffa05850ea>] ? nf_nat_cleanup_conntrack+0x69/0x6d [nf_nat]
694 <IRQ> [<ffffffff813a5c5b>] netdev_rx_csum_fault+0x3b/0x3f
^ permalink raw reply
* [46/54] xen: netfront: explicitly generate arp_notify event after migration.
From: Greg KH @ 2010-08-12 0:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jeremy Fitzhardinge, xen-devel, Ian Campbell, torvalds,
David S. Miller, netdev, akpm, Stephen Hemminger, stable-review,
alan
In-Reply-To: <20100812000249.GA30948@kroah.com>
2.6.34-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 592970675c9522bde588b945388c7995c8b51328 upstream.
Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
generated after a migration.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1621,6 +1621,7 @@ static void backend_changed(struct xenbu
if (xennet_connect(netdev) != 0)
break;
xenbus_switch_state(dev, XenbusStateConnected);
+ netif_notify_peers(netdev);
break;
case XenbusStateClosing:
^ permalink raw reply
* [45/54] arp_notify: allow drivers to explicitly request a notification event.
From: Greg KH @ 2010-08-12 0:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Ian Campbell,
Stephen Hemminger, Jeremy Fitzhardinge, David S. Miller, netdev
In-Reply-To: <20100812000249.GA30948@kroah.com>
2.6.34-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.
Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/netdevice.h | 2 ++
include/linux/notifier.h | 1 +
net/ipv4/devinet.c | 1 +
net/sched/sch_generic.c | 18 ++++++++++++++++++
4 files changed, 22 insertions(+)
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1661,6 +1661,8 @@ extern void netif_carrier_on(struct net_
extern void netif_carrier_off(struct net_device *dev);
+extern void netif_notify_peers(struct net_device *dev);
+
/**
* netif_dormant_on - mark device as dormant.
* @dev: network device
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -203,6 +203,7 @@ static inline int notifier_to_errno(int
#define NETDEV_BONDING_NEWTYPE 0x000F
#define NETDEV_POST_INIT 0x0010
#define NETDEV_UNREGISTER_BATCH 0x0011
+#define NETDEV_NOTIFY_PEERS 0x0012
#define SYS_DOWN 0x0001 /* Notify of system down */
#define SYS_RESTART SYS_DOWN
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1081,6 +1081,7 @@ static int inetdev_event(struct notifier
}
ip_mc_up(in_dev);
/* fall through */
+ case NETDEV_NOTIFY_PEERS:
case NETDEV_CHANGEADDR:
/* Send gratuitous ARP to notify of link change */
if (IN_DEV_ARP_NOTIFY(in_dev)) {
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -325,6 +325,24 @@ void netif_carrier_off(struct net_device
}
EXPORT_SYMBOL(netif_carrier_off);
+/**
+ * netif_notify_peers - notify network peers about existence of @dev
+ * @dev: network device
+ *
+ * Generate traffic such that interested network peers are aware of
+ * @dev, such as by generating a gratuitous ARP. This may be used when
+ * a device wants to inform the rest of the network about some sort of
+ * reconfiguration such as a failover event or virtual machine
+ * migration.
+ */
+void netif_notify_peers(struct net_device *dev)
+{
+ rtnl_lock();
+ call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev);
+ rtnl_unlock();
+}
+EXPORT_SYMBOL(netif_notify_peers);
+
/* "NOOP" scheduler: the best scheduler, recommended for all interfaces
under all circumstances. It is difficult to invent anything faster or
cheaper.
^ permalink raw reply
* [037/111] xen: netfront: explicitly generate arp_notify event after migration.
From: Greg KH @ 2010-08-11 23:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jeremy Fitzhardinge, xen-devel, Ian Campbell, torvalds,
David S. Miller, netdev, akpm, Stephen Hemminger, stable-review,
alan
In-Reply-To: <20100811235623.GA24440@kroah.com>
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 592970675c9522bde588b945388c7995c8b51328 upstream.
Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
generated after a migration.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1619,6 +1619,7 @@ static void backend_changed(struct xenbu
if (xennet_connect(netdev) != 0)
break;
xenbus_switch_state(dev, XenbusStateConnected);
+ netif_notify_peers(netdev);
break;
case XenbusStateClosing:
^ permalink raw reply
* [036/111] arp_notify: allow drivers to explicitly request a notification event.
From: Greg KH @ 2010-08-11 23:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Ian Campbell,
Stephen Hemminger, Jeremy Fitzhardinge, David S. Miller, netdev
In-Reply-To: <20100811235623.GA24440@kroah.com>
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.
Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/netdevice.h | 2 ++
include/linux/notifier.h | 1 +
net/ipv4/devinet.c | 1 +
net/sched/sch_generic.c | 18 ++++++++++++++++++
4 files changed, 22 insertions(+)
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1560,6 +1560,8 @@ extern void netif_carrier_on(struct net_
extern void netif_carrier_off(struct net_device *dev);
+extern void netif_notify_peers(struct net_device *dev);
+
/**
* netif_dormant_on - mark device as dormant.
* @dev: network device
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -201,6 +201,7 @@ static inline int notifier_to_errno(int
#define NETDEV_PRE_UP 0x000D
#define NETDEV_BONDING_OLDTYPE 0x000E
#define NETDEV_BONDING_NEWTYPE 0x000F
+#define NETDEV_NOTIFY_PEERS 0x0012
#define SYS_DOWN 0x0001 /* Notify of system down */
#define SYS_RESTART SYS_DOWN
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1076,6 +1076,7 @@ static int inetdev_event(struct notifier
}
ip_mc_up(in_dev);
/* fall through */
+ case NETDEV_NOTIFY_PEERS:
case NETDEV_CHANGEADDR:
/* Send gratuitous ARP to notify of link change */
if (IN_DEV_ARP_NOTIFY(in_dev)) {
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -330,6 +330,24 @@ void netif_carrier_off(struct net_device
}
EXPORT_SYMBOL(netif_carrier_off);
+/**
+ * netif_notify_peers - notify network peers about existence of @dev
+ * @dev: network device
+ *
+ * Generate traffic such that interested network peers are aware of
+ * @dev, such as by generating a gratuitous ARP. This may be used when
+ * a device wants to inform the rest of the network about some sort of
+ * reconfiguration such as a failover event or virtual machine
+ * migration.
+ */
+void netif_notify_peers(struct net_device *dev)
+{
+ rtnl_lock();
+ call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev);
+ rtnl_unlock();
+}
+EXPORT_SYMBOL(netif_notify_peers);
+
/* "NOOP" scheduler: the best scheduler, recommended for all interfaces
under all circumstances. It is difficult to invent anything faster or
cheaper.
^ permalink raw reply
* Re: [PATCH 2/2] ipw2100: add WEXT scan capabilities
From: Dan Williams @ 2010-08-11 23:32 UTC (permalink / raw)
To: Christoph Fritz
Cc: John W. Linville, Zhu Yi, David S. Miller, Joe Perches,
Rafael J. Wysocki, linux-wireless, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <1281555195.4367.3.camel@lovely.krouter>
On Wed, 2010-08-11 at 21:33 +0200, Christoph Fritz wrote:
> NetworkManager claims: "driver does not support SSID scans (scan_capa
> 0x00)". This patch adds scan capabilities.
NAK
It just doesn't. Take a look at ipw2100_wx_set_scan(); there's no
handling of any SSID stuff in there. The driver does not support
probe-scans; I'm not sure if the firmware does, but even if it does, the
driver doesn't send the SSID down to the firmware.
Compare this to the ipw2200.c set_scan() function. It just does not
appear that the ipw2100 supports arbitrary SSIDs for direct scans, which
is why I didn't include this capability when I went around patching the
drivers a few years ago.
Dan
> Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
> ---
> drivers/net/wireless/ipw2x00/ipw2100.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
> index df8e535..c330da4 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2100.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2100.c
> @@ -6982,12 +6982,15 @@ static int ipw2100_wx_get_range(struct net_device *dev,
>
> /* Event capability (kernel + driver) */
> range->event_capa[0] = (IW_EVENT_CAPA_K_0 |
> - IW_EVENT_CAPA_MASK(SIOCGIWAP));
> + IW_EVENT_CAPA_MASK(SIOCGIWAP) |
> + IW_EVENT_CAPA_MASK(SIOCGIWSCAN));
> range->event_capa[1] = IW_EVENT_CAPA_K_1;
>
> range->enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 |
> IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP;
>
> + range->scan_capa = IW_SCAN_CAPA_ESSID | IW_SCAN_CAPA_TYPE;
> +
> IPW_DEBUG_WX("GET Range\n");
>
> return 0;
^ permalink raw reply
* [PATCH -next] phylib: available for any speed ethernet
From: Randy Dunlap @ 2010-08-11 23:26 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Several gigabit network drivers (SB1250_MAC, TIGON3, FSL, GIANFAR,
UCC_GETH, MV643XX_ETH, XILINX_LL_TEMAC, S6GMAC, STMMAC_ETH, PASEMI_MAC,
and OCTEON_ETHERNET) select PHYLIB. These drivers are not under
NET_ETHERNET (10/100 mbit), so this warning is generated (long, irrelevant
parts are omitted):
warning: (NET_DSA && NET && EXPERIMENTAL && NET_ETHERNET && !S390 || ... || SB1250_MAC && NETDEVICES && NETDEV_1000 && SIBYTE_SB1xxx_SOC || TIGON3 && NETDEVICES && NETDEV_1000 && PCI || FSL_PQ_MDIO && NETDEVICES && NETDEV_1000 && FSL_SOC || GIANFAR && NETDEVICES && NETDEV_1000 && FSL_SOC || UCC_GETH && NETDEVICES && NETDEV_1000 && QUICC_ENGINE || MV643XX_ETH && NETDEVICES && NETDEV_1000 && (MV64X60 || PPC32 || PLAT_ORION) || XILINX_LL_TEMAC && NETDEVICES && NETDEV_1000 && (PPC || MICROBLAZE) || S6GMAC && NETDEVICES && NETDEV_1000 && XTENSA_VARIANT_S6000 || STMMAC_ETH && NETDEV_1000 && NETDEVICES && CPU_SUBTYPE_ST40 || PASEMI_MAC && NETDEVICES && NETDEV_10000 && PPC_PASEMI && PCI || OCTEON_ETHERNET && STAGING && !STAGING_EXCLUDE_BUILD && CPU_CAVIUM_OCTEON) selects PHYLIB which has unmet dir
ect dependencies (!S390 && NET_ETHERNET)
PHYLIB is used by non-10/100 mbit ethernet drivers, so change the dependencies
to be NETDEVICES instead of NET_ETHERNET.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/phy/Kconfig | 2 +-
net/dsa/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20100810.orig/drivers/net/phy/Kconfig
+++ linux-next-20100810/drivers/net/phy/Kconfig
@@ -5,7 +5,7 @@
menuconfig PHYLIB
tristate "PHY Device support and infrastructure"
depends on !S390
- depends on NET_ETHERNET
+ depends on NETDEVICES
help
Ethernet controllers are usually attached to PHY
devices. This option provides infrastructure for
--- linux-next-20100810.orig/net/dsa/Kconfig
+++ linux-next-20100810/net/dsa/Kconfig
@@ -1,7 +1,7 @@
menuconfig NET_DSA
bool "Distributed Switch Architecture support"
default n
- depends on EXPERIMENTAL && NET_ETHERNET && !S390
+ depends on EXPERIMENTAL && NETDEVICES && !S390
select PHYLIB
---help---
This allows you to use hardware switch chips that use
^ permalink raw reply
* Re: [PATCH] can: add limit for nframes and clean up signed/unsigned variables
From: David Miller @ 2010-08-11 23:12 UTC (permalink / raw)
To: socketcan; +Cc: hawkes, urs.thuermann, netdev
In-Reply-To: <4C627102.1080205@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Wed, 11 Aug 2010 11:44:34 +0200
> This patch adds a limit for nframes as the number of frames in TX_SETUP and
> RX_SETUP are derived from a single byte multiplex value by default.
> Use-cases that would require to send/filter more than 256 CAN frames should
> be implemented in userspace for complexity reasons anyway.
>
> Additionally the assignments of unsigned values from userspace to signed
> values in kernelspace and vice versa are fixed by using unsigned values in
> kernelspace consistently.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Reported-by: Ben Hawkes <hawkes@google.com>
> Acked-by: Urs Thuermann <urs.thuermann@volkswagen.de>
Applied and I'll queue this up for -stable, thanks.
^ 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