* Re: mmotm 2009-08-04-14-22 uploaded
From: Andrew Morton @ 2009-08-05 7:06 UTC (permalink / raw)
To: Dave Young; +Cc: linux-kernel, netdev, Peter Zijlstra, Jiri Pirko
In-Reply-To: <20090805063946.GA1934@darkstar>
On Wed, 5 Aug 2009 14:39:46 +0800 Dave Young <hidave.darkstar@gmail.com> wrote:
> Hi andrew,
>
> I see following lockdep warning with this release:
>
> [ 0.474144] INFO: trying to register non-static key.
> [ 0.474144] the code is fine but needs lockdep annotation.
> [ 0.474144] turning off the locking correctness validator.
> [ 0.474144] Pid: 1, comm: swapper Not tainted 2.6.31-rc5-mm1 #7
> [ 0.474144] Call Trace:
> [ 0.474144] [<c1047f1e>] register_lock_class+0x58/0x241
> [ 0.474144] [<c1049ab1>] __lock_acquire+0xac/0xb73
> [ 0.474144] [<c1076eb5>] ? __alloc_pages_nodemask+0xe2/0x483
> [ 0.474144] [<c1048b64>] ? mark_lock+0x1e/0x1c7
> [ 0.474144] [<c1048b64>] ? mark_lock+0x1e/0x1c7
> [ 0.474144] [<c1048d50>] ? mark_held_locks+0x43/0x5b
> [ 0.474144] [<c10940a6>] ? kmem_cache_alloc+0xac/0x11b
> [ 0.474144] [<c104a615>] lock_acquire+0x9d/0xc0
> [ 0.474144] [<c12b8b96>] ? netif_addr_lock_bh+0xd/0xf
> [ 0.474144] [<c1330feb>] _spin_lock_bh+0x20/0x2f
> [ 0.474144] [<c12b8b96>] ? netif_addr_lock_bh+0xd/0xf
> [ 0.474144] [<c12b8b96>] netif_addr_lock_bh+0xd/0xf
> [ 0.474144] [<c12bc3c3>] alloc_netdev_mq+0xf9/0x1a5
> [ 0.474144] [<c121f016>] ? loopback_setup+0x0/0x74
> [ 0.474144] [<c1578d49>] loopback_net_init+0x20/0x5d
> [ 0.474144] [<c12b7907>] register_pernet_operations+0x13/0x15
> [ 0.474144] [<c12b7970>] register_pernet_device+0x1f/0x47
> [ 0.474144] [<c157ee8d>] net_dev_init+0xfe/0x14d
> [ 0.474144] [<c1001137>] do_one_initcall+0x4a/0x11a
> [ 0.474144] [<c157ed8f>] ? net_dev_init+0x0/0x14d
> [ 0.474144] [<c1067e00>] ? register_irq_proc+0x64/0xa8
> [ 0.474144] [<c1067e97>] ? init_irq_proc+0x53/0x60
> [ 0.474144] [<c1557535>] kernel_init+0x129/0x17a
> [ 0.474144] [<c155740c>] ? kernel_init+0x0/0x17a
> [ 0.474144] [<c1003d47>] kernel_thread_helper+0x7/0x10
At a guess I'd say that alloc_netdev_mq()->dev_unicast_init() is doing
netif_addr_lock_bh()->spin_lock_bh(&dev->addr_list_lock) prior to
initialising add_list_lock.
Something like this might shut it up:
--- a/net/core/dev.c~a
+++ a/net/core/dev.c
@@ -5111,7 +5111,7 @@ struct net_device *alloc_netdev_mq(int s
if (dev_addr_init(dev))
goto free_tx;
- dev_unicast_init(dev);
+ __hw_addr_init(&dev->uc);
dev_net_set(dev, &init_net);
but it'd be better to intialise this thing earlier like:
--- a/net/core/dev.c~a
+++ a/net/core/dev.c
@@ -4730,8 +4730,6 @@ int register_netdevice(struct net_device
BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);
BUG_ON(!net);
- spin_lock_init(&dev->addr_list_lock);
- netdev_set_addr_lockdep_class(dev);
netdev_init_queue_locks(dev);
dev->iflink = -1;
@@ -5107,6 +5105,8 @@ struct net_device *alloc_netdev_mq(int s
dev = PTR_ALIGN(p, NETDEV_ALIGN);
dev->padded = (char *)dev - (char *)p;
+ spin_lock_init(&dev->addr_list_lock);
+ netdev_set_addr_lockdep_class(dev);
if (dev_addr_init(dev))
goto free_tx;
_
but that might break register_netdevice() for netdevs which were
allocated via other means, dunno.
I would be pointing fingers at
: commit 31278e71471399beaff9280737e52b47db4dc345
: Author: Jiri Pirko <jpirko@redhat.com>
: AuthorDate: Wed Jun 17 01:12:19 2009 +0000
: Commit: David S. Miller <davem@davemloft.net>
: CommitDate: Thu Jun 18 00:29:08 2009 -0700
:
: net: group address list and its count
and politely suggesting that net developers enable lockdep when testing :)
^ permalink raw reply
* Re: mmotm 2009-08-04-14-22 uploaded
From: Eric Dumazet @ 2009-08-05 7:14 UTC (permalink / raw)
To: Dave Young
Cc: akpm, mm-commits, linux-kernel, Linux Netdev List,
David S. Miller, Jiri Pirko, Ingo Molnar
In-Reply-To: <20090805063946.GA1934@darkstar>
Dave Young a écrit :
> Hi andrew,
>
> I see following lockdep warning with this release:
>
> [ 0.474144] INFO: trying to register non-static key.
> [ 0.474144] the code is fine but needs lockdep annotation.
> [ 0.474144] turning off the locking correctness validator.
> [ 0.474144] Pid: 1, comm: swapper Not tainted 2.6.31-rc5-mm1 #7
> [ 0.474144] Call Trace:
> [ 0.474144] [<c1047f1e>] register_lock_class+0x58/0x241
> [ 0.474144] [<c1049ab1>] __lock_acquire+0xac/0xb73
> [ 0.474144] [<c1076eb5>] ? __alloc_pages_nodemask+0xe2/0x483
> [ 0.474144] [<c1048b64>] ? mark_lock+0x1e/0x1c7
> [ 0.474144] [<c1048b64>] ? mark_lock+0x1e/0x1c7
> [ 0.474144] [<c1048d50>] ? mark_held_locks+0x43/0x5b
> [ 0.474144] [<c10940a6>] ? kmem_cache_alloc+0xac/0x11b
> [ 0.474144] [<c104a615>] lock_acquire+0x9d/0xc0
> [ 0.474144] [<c12b8b96>] ? netif_addr_lock_bh+0xd/0xf
> [ 0.474144] [<c1330feb>] _spin_lock_bh+0x20/0x2f
> [ 0.474144] [<c12b8b96>] ? netif_addr_lock_bh+0xd/0xf
> [ 0.474144] [<c12b8b96>] netif_addr_lock_bh+0xd/0xf
> [ 0.474144] [<c12bc3c3>] alloc_netdev_mq+0xf9/0x1a5
> [ 0.474144] [<c121f016>] ? loopback_setup+0x0/0x74
> [ 0.474144] [<c1578d49>] loopback_net_init+0x20/0x5d
> [ 0.474144] [<c12b7907>] register_pernet_operations+0x13/0x15
> [ 0.474144] [<c12b7970>] register_pernet_device+0x1f/0x47
> [ 0.474144] [<c157ee8d>] net_dev_init+0xfe/0x14d
> [ 0.474144] [<c1001137>] do_one_initcall+0x4a/0x11a
> [ 0.474144] [<c157ed8f>] ? net_dev_init+0x0/0x14d
> [ 0.474144] [<c1067e00>] ? register_irq_proc+0x64/0xa8
> [ 0.474144] [<c1067e97>] ? init_irq_proc+0x53/0x60
> [ 0.474144] [<c1557535>] kernel_init+0x129/0x17a
> [ 0.474144] [<c155740c>] ? kernel_init+0x0/0x17a
> [ 0.474144] [<c1003d47>] kernel_thread_helper+0x7/0x10
>
> --
Hmm, it seems addr_list_lock is not initialized at the right place...
commit a6ac65db addded a netif_addr_lock_bh() in dev_unicast_init()
We initialize dev->addr_list_lock in register_netdevice(), we should
init it earlier, right after allocation and before dev_unicast_init()
But dev->type being 0, we probably cannot call netdev_set_addr_lockdep_class()
at this point...
David, what do you think ? Is it safe to call netdev_set_addr_lockdep_class()
in register_netdevice(), after lock being used one time in dev_unicast_init() ?
Thank you
[PATCH] net: Init dev->addr_list_lock in alloc_netdev_mq()
We initialize dev->addr_list_lock in register_netdevice(), we should
init it earlier, right after allocation and before dev_unicast_init()
Reported-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 43e61ba..e50356b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4728,7 +4728,6 @@ int register_netdevice(struct net_device *dev)
BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);
BUG_ON(!net);
- spin_lock_init(&dev->addr_list_lock);
netdev_set_addr_lockdep_class(dev);
netdev_init_queue_locks(dev);
@@ -5106,6 +5105,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev = PTR_ALIGN(p, NETDEV_ALIGN);
dev->padded = (char *)dev - (char *)p;
+ spin_lock_init(&dev->addr_list_lock);
if (dev_addr_init(dev))
goto free_tx;
^ permalink raw reply related
* Re: [GIT]: Networking
From: Ingo Molnar @ 2009-08-05 7:14 UTC (permalink / raw)
To: David Miller, Peter Zijlstra, Jiri Pirko
Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20090805070205.GA8741@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> FYI, -tip testing found that these bits trigger a missing lockdep
> annotation warning:
it's apparently using an zero-initialized spinlock. This is a
side-effect of:
dev_unicast_init(dev);
in alloc_netdev_mq() making use of dev->addr_list_lock.
Wouldnt the patch below be the right fix? The device has just been
allocated freshly, it's not accessible anywhere yet so no locking is
needed at all - in fact it's wrong to lock it here (the lock isnt
initialized yet).
This bug was apparently introduced via:
| commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
| Author: Jiri Pirko <jpirko@redhat.com>
| Date: Thu Jul 30 01:06:12 2009 +0000
|
| net: restore the original spinlock to protect unicast list
it needlessly added new locking and apparently nobody ran this patch
with lockdep.
Ingo
Index: linux2/net/core/dev.c
===================================================================
--- linux2.orig/net/core/dev.c
+++ linux2/net/core/dev.c
@@ -4007,9 +4007,7 @@ static void dev_unicast_flush(struct net
static void dev_unicast_init(struct net_device *dev)
{
- netif_addr_lock_bh(dev);
__hw_addr_init(&dev->uc);
- netif_addr_unlock_bh(dev);
}
^ permalink raw reply
* [PATCH] net: Fix spinlock use in alloc_netdev_mq()
From: Ingo Molnar @ 2009-08-05 7:16 UTC (permalink / raw)
To: David Miller, Peter Zijlstra, Jiri Pirko
Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20090805071411.GA9217@elte.hu>
>From 6a0405d0e9b5e15bb81b8278b08fdb931a6e8837 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Wed, 5 Aug 2009 09:14:11 +0200
Subject: [PATCH] net: Fix spinlock use in alloc_netdev_mq()
-tip testing found this lockdep warning:
[ 2.272010] calling net_dev_init+0x0/0x164 @ 1
[ 2.276033] device class 'net': registering
[ 2.280191] INFO: trying to register non-static key.
[ 2.284005] the code is fine but needs lockdep annotation.
[ 2.284005] turning off the locking correctness validator.
[ 2.284005] Pid: 1, comm: swapper Not tainted 2.6.31-rc5-tip #1145
[ 2.284005] Call Trace:
[ 2.284005] [<7958eb4e>] ? printk+0xf/0x11
[ 2.284005] [<7904f83c>] __lock_acquire+0x11b/0x622
[ 2.284005] [<7908c9b7>] ? alloc_debug_processing+0xf9/0x144
[ 2.284005] [<7904e2be>] ? mark_held_locks+0x3a/0x52
[ 2.284005] [<7908dbc4>] ? kmem_cache_alloc+0xa8/0x13f
[ 2.284005] [<7904e475>] ? trace_hardirqs_on_caller+0xa2/0xc3
[ 2.284005] [<7904fdf6>] lock_acquire+0xb3/0xd0
[ 2.284005] [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
[ 2.284005] [<79591514>] _spin_lock_bh+0x2d/0x5d
[ 2.284005] [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
[ 2.284005] [<79489678>] alloc_netdev_mq+0xf5/0x1ad
[ 2.284005] [<793a38f2>] ? loopback_setup+0x0/0x74
[ 2.284005] [<798eecd0>] loopback_net_init+0x20/0x5d
[ 2.284005] [<79483efb>] register_pernet_device+0x23/0x4b
[ 2.284005] [<798f5c9f>] net_dev_init+0x115/0x164
[ 2.284005] [<7900104f>] do_one_initcall+0x4a/0x11a
[ 2.284005] [<798f5b8a>] ? net_dev_init+0x0/0x164
[ 2.284005] [<79066f6d>] ? register_irq_proc+0x8c/0xa8
[ 2.284005] [<798cc29a>] do_basic_setup+0x42/0x52
[ 2.284005] [<798cc30a>] kernel_init+0x60/0xa1
[ 2.284005] [<798cc2aa>] ? kernel_init+0x0/0xa1
[ 2.284005] [<79003e03>] kernel_thread_helper+0x7/0x10
[ 2.284078] device: 'lo': device_add
[ 2.288248] initcall net_dev_init+0x0/0x164 returned 0 after 11718 usecs
[ 2.292010] calling neigh_init+0x0/0x66 @ 1
[ 2.296010] initcall neigh_init+0x0/0x66 returned 0 after 0 usecs
it's using an zero-initialized spinlock. This is a side-effect of:
dev_unicast_init(dev);
in alloc_netdev_mq() making use of dev->addr_list_lock.
The device has just been allocated freshly, it's not accessible
anywhere yet so no locking is needed at all - in fact it's wrong
to lock it here (the lock isnt initialized yet).
This bug was introduced via:
| commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
| Date: Thu Jul 30 01:06:12 2009 +0000
|
| net: restore the original spinlock to protect unicast list
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
net/core/dev.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 43e61ba..6a94475 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4007,9 +4007,7 @@ static void dev_unicast_flush(struct net_device *dev)
static void dev_unicast_init(struct net_device *dev)
{
- netif_addr_lock_bh(dev);
__hw_addr_init(&dev->uc);
- netif_addr_unlock_bh(dev);
}
^ permalink raw reply related
* Re: [GIT]: Networking
From: Eric Dumazet @ 2009-08-05 7:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Miller, Peter Zijlstra, Jiri Pirko, torvalds, akpm, netdev,
linux-kernel
In-Reply-To: <20090805071411.GA9217@elte.hu>
Ingo Molnar a écrit :
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> FYI, -tip testing found that these bits trigger a missing lockdep
>> annotation warning:
>
> it's apparently using an zero-initialized spinlock. This is a
> side-effect of:
>
> dev_unicast_init(dev);
>
> in alloc_netdev_mq() making use of dev->addr_list_lock.
>
> Wouldnt the patch below be the right fix? The device has just been
> allocated freshly, it's not accessible anywhere yet so no locking is
> needed at all - in fact it's wrong to lock it here (the lock isnt
> initialized yet).
>
> This bug was apparently introduced via:
>
> | commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
> | Author: Jiri Pirko <jpirko@redhat.com>
> | Date: Thu Jul 30 01:06:12 2009 +0000
> |
> | net: restore the original spinlock to protect unicast list
>
> it needlessly added new locking and apparently nobody ran this patch
> with lockdep.
>
> Ingo
>
> Index: linux2/net/core/dev.c
> ===================================================================
> --- linux2.orig/net/core/dev.c
> +++ linux2/net/core/dev.c
> @@ -4007,9 +4007,7 @@ static void dev_unicast_flush(struct net
>
> static void dev_unicast_init(struct net_device *dev)
> {
> - netif_addr_lock_bh(dev);
> __hw_addr_init(&dev->uc);
> - netif_addr_unlock_bh(dev);
> }
>
>
Indeed, this function is static and thus only called from alloc_netdev_mq()
^ permalink raw reply
* [GIT PULL 0/3] IEEE 802.15.4 last-minute fixes v2
From: Dmitry Eremin-Solenikov @ 2009-08-05 7:28 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
Please pull several minor fixes for the IEEE 802.15.4 stack.
The following changes since commit db71789c01ae7b641f83c5aa64e7df25122f4b28:
David S. Miller (1):
xfrm6: Fix xfrm6_policy.c build when SYSCTL disabled.
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-linus
Dmitry Eremin-Solenikov (3):
af_ieee802154: fix ioctl processing
af_ieee802154: provide dummy get/setsockopt
documentation: fix wrt. headers rename
Documentation/networking/ieee802154.txt | 9 ++++-----
net/ieee802154/af_ieee802154.c | 8 +++++---
net/ieee802154/dgram.c | 14 ++++++++++++++
net/ieee802154/raw.c | 14 ++++++++++++++
4 files changed, 37 insertions(+), 8 deletions(-)
--
With best wishes
Dmitry Eremin-Solenikov
^ permalink raw reply
* [PATCH 1/3] af_ieee802154: fix ioctl processing
From: Dmitry Eremin-Solenikov @ 2009-08-05 7:28 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249457297-8355-1-git-send-email-dbaryshkov@gmail.com>
fix two errors in ioctl processing:
1) if the ioctl isn't supported one should return -ENOIOCTLCMD
2) don't call ndo_do_ioctl if the device doesn't provide it
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
net/ieee802154/af_ieee802154.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/af_ieee802154.c b/net/ieee802154/af_ieee802154.c
index 69c8d92..d504c34 100644
--- a/net/ieee802154/af_ieee802154.c
+++ b/net/ieee802154/af_ieee802154.c
@@ -136,7 +136,7 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
unsigned int cmd)
{
struct ifreq ifr;
- int ret = -EINVAL;
+ int ret = -ENOIOCTLCMD;
struct net_device *dev;
if (copy_from_user(&ifr, arg, sizeof(struct ifreq)))
@@ -146,8 +146,10 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
dev_load(sock_net(sk), ifr.ifr_name);
dev = dev_get_by_name(sock_net(sk), ifr.ifr_name);
- if (dev->type == ARPHRD_IEEE802154 ||
- dev->type == ARPHRD_IEEE802154_PHY)
+
+ if ((dev->type == ARPHRD_IEEE802154 ||
+ dev->type == ARPHRD_IEEE802154_PHY) &&
+ dev->netdev_ops->ndo_do_ioctl)
ret = dev->netdev_ops->ndo_do_ioctl(dev, &ifr, cmd);
if (!ret && copy_to_user(arg, &ifr, sizeof(struct ifreq)))
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] af_ieee802154: provide dummy get/setsockopt
From: Dmitry Eremin-Solenikov @ 2009-08-05 7:28 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249457297-8355-2-git-send-email-dbaryshkov@gmail.com>
Provide dummt get/setsockopt implementations to stop these
syscalls from oopsing on our sockets.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
net/ieee802154/dgram.c | 14 ++++++++++++++
net/ieee802154/raw.c | 14 ++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 53dd912..d1da6c6 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -377,6 +377,18 @@ int ieee802154_dgram_deliver(struct net_device *dev, struct sk_buff *skb)
return ret;
}
+static int dgram_getsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user *optlen)
+{
+ return -EOPNOTSUPP;
+}
+
+static int dgram_setsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user optlen)
+{
+ return -EOPNOTSUPP;
+}
+
struct proto ieee802154_dgram_prot = {
.name = "IEEE-802.15.4-MAC",
.owner = THIS_MODULE,
@@ -391,5 +403,7 @@ struct proto ieee802154_dgram_prot = {
.connect = dgram_connect,
.disconnect = dgram_disconnect,
.ioctl = dgram_ioctl,
+ .getsockopt = dgram_getsockopt,
+ .setsockopt = dgram_setsockopt,
};
diff --git a/net/ieee802154/raw.c b/net/ieee802154/raw.c
index ea8d1f1..60dee69 100644
--- a/net/ieee802154/raw.c
+++ b/net/ieee802154/raw.c
@@ -238,6 +238,18 @@ void ieee802154_raw_deliver(struct net_device *dev, struct sk_buff *skb)
read_unlock(&raw_lock);
}
+static int raw_getsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user *optlen)
+{
+ return -EOPNOTSUPP;
+}
+
+static int raw_setsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user optlen)
+{
+ return -EOPNOTSUPP;
+}
+
struct proto ieee802154_raw_prot = {
.name = "IEEE-802.15.4-RAW",
.owner = THIS_MODULE,
@@ -250,5 +262,7 @@ struct proto ieee802154_raw_prot = {
.unhash = raw_unhash,
.connect = raw_connect,
.disconnect = raw_disconnect,
+ .getsockopt = raw_getsockopt,
+ .setsockopt = raw_setsockopt,
};
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] documentation: fix wrt. headers rename
From: Dmitry Eremin-Solenikov @ 2009-08-05 7:28 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249457297-8355-3-git-send-email-dbaryshkov@gmail.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
Documentation/networking/ieee802154.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1d4ed66..1c0c82c 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -22,7 +22,7 @@ int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
.....
The address family, socket addresses etc. are defined in the
-include/net/ieee802154/af_ieee802154.h header or in the special header
+include/net/af_ieee802154.h header or in the special header
in our userspace package (see either linux-zigbee sourceforge download page
or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).
@@ -33,7 +33,7 @@ MLME - MAC Level Management
============================
Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
-See the include/net/ieee802154/nl802154.h header. Our userspace tools package
+See the include/net/nl802154.h header. Our userspace tools package
(see above) provides CLI configuration utility for radio interfaces and simple
coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
@@ -54,7 +54,7 @@ Those types of devices require different approach to be hooked into Linux kernel
HardMAC
=======
-See the header include/net/ieee802154/netdevice.h. You have to implement Linux
+See the header include/net/ieee802154_netdev.h. You have to implement Linux
net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
code via plain sk_buffs. The control block of sk_buffs will contain additional
info as described in the struct ieee802154_mac_cb.
@@ -72,5 +72,4 @@ SoftMAC
We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
in software. This is currently WIP.
-See header include/net/ieee802154/mac802154.h and several drivers in
-drivers/ieee802154/
+See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
--
1.6.3.3
^ permalink raw reply related
* Re: [GIT PULL 0/5] IEEE 802.15.4 last-minute fixes.
From: Dmitry Eremin-Solenikov @ 2009-08-05 7:31 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20090804.090921.198630830.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, Aug 04, 2009 at 09:09:21AM -0700, David Miller wrote:
> From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Tue, 4 Aug 2009 18:48:10 +0400
>
> > On Tue, Aug 04, 2009 at 05:58:10AM -0700, David Miller wrote:
> >> From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Date: Tue, 4 Aug 2009 12:51:48 +0400
> >>
> >> > Will you pull the serie if I'll remove those two patches? Documentation
> >> > fix isn't that important, however I'd really ask to pull the remaining
> >> > two patches.
> >>
> >> Yes.
> >
> > Pushed the updated branch. Please pull.
>
> Please don't resubmit changes like this. It screws up all the
> nice tracking of every patch we do on patchwork for networking
> changes.
>
> Please make a formal, full, reposting of the patch series you want me
> to apply. That way they can be tracked in patchwork, and the patches
> can be replied to and commented upon (and such comments tracked in
> patchwork as well).
>
> When I say I'm tossing someone's changes, that means if they resubmit
> they have to really resubmit everything, the patch postings at all.
> Don't short-cut it with just a GIT tree refresh and pull request.
Sorry for the troubles from our side. We are still learning how to do
things correctly. The patchserie (cut to 3 patches) is resubmitted
in a clean way.
--
With best wishes
Dmitry
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: Jussi Mäki @ 2009-08-05 7:41 UTC (permalink / raw)
To: netdev
Hi,
The current xfrm hash functions perform very poorly when a number of
policies have the same
last byte in source and destination addresses.
For example with __xfrm_dst_hash, hmask of 0xfff:
192.168.0.1-172.16.0.1 hashes to 3258
192.168.0.2-172.16.0.2 hashes to 3258
... and so on.
This patch addresses the issue by rewriting the xfrm
hash functions to use the Jenkins' hash function.
Signed-off-by: Jussi Maki <joamaki@gmail.com>
---
net/xfrm/xfrm_hash.h | 90 ++++++++++++++++++++++++++-----------------------
1 files changed, 48 insertions(+), 42 deletions(-)
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index d401dc8..59d4cb6 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -3,6 +3,7 @@
#include <linux/xfrm.h>
#include <linux/socket.h>
+#include <linux/jhash.h>
static inline unsigned int __xfrm4_addr_hash(xfrm_address_t *addr)
{
@@ -14,31 +15,27 @@ static inline unsigned int
__xfrm6_addr_hash(xfrm_address_t *addr)
return ntohl(addr->a6[2] ^ addr->a6[3]);
}
-static inline unsigned int __xfrm4_daddr_saddr_hash(xfrm_address_t
*daddr, xfrm_address_t *saddr)
-{
- return ntohl(daddr->a4 ^ saddr->a4);
-}
-
-static inline unsigned int __xfrm6_daddr_saddr_hash(xfrm_address_t
*daddr, xfrm_address_t *saddr)
-{
- return ntohl(daddr->a6[2] ^ daddr->a6[3] ^
- saddr->a6[2] ^ saddr->a6[3]);
-}
-
-static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr,
xfrm_address_t *saddr,
- u32 reqid, unsigned short family,
+static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr,
+ xfrm_address_t *saddr,
+ u32 reqid,
+ unsigned short family,
unsigned int hmask)
{
- unsigned int h = family ^ reqid;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
+
switch (family) {
case AF_INET:
- h ^= __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_daddr_saddr_hash(daddr, saddr);
- break;
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
}
- return (h ^ (h >> 16)) & hmask;
+
+ return jhash_3words(shash, dhash,
+ reqid, family) & hmask;
}
static inline unsigned __xfrm_src_hash(xfrm_address_t *daddr,
@@ -46,32 +43,37 @@ static inline unsigned
__xfrm_src_hash(xfrm_address_t *daddr,
unsigned short family,
unsigned int hmask)
{
- unsigned int h = family;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
switch (family) {
case AF_INET:
- h ^= __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_daddr_saddr_hash(daddr, saddr);
- break;
- };
- return (h ^ (h >> 16)) & hmask;
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
+ }
+ return jhash_2words(shash, dhash, family) & hmask;
}
static inline unsigned int
-__xfrm_spi_hash(xfrm_address_t *daddr, __be32 spi, u8 proto, unsigned
short family,
+__xfrm_spi_hash(xfrm_address_t *daddr, __be32 spi, u8 proto,
+ unsigned short family,
unsigned int hmask)
{
- unsigned int h = (__force u32)spi ^ proto;
+ unsigned int h = 0;
+
switch (family) {
case AF_INET:
- h ^= __xfrm4_addr_hash(daddr);
+ h = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_addr_hash(daddr);
+ h = __xfrm6_addr_hash(daddr);
break;
}
- return (h ^ (h >> 10) ^ (h >> 20)) & hmask;
+
+ return jhash_3words(h, spi, proto, family) & hmask;
}
static inline unsigned int __idx_hash(u32 index, unsigned int hmask)
@@ -83,7 +85,8 @@ static inline unsigned int __sel_hash(struct
xfrm_selector *sel, unsigned short
{
xfrm_address_t *daddr = &sel->daddr;
xfrm_address_t *saddr = &sel->saddr;
- unsigned int h = 0;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
switch (family) {
case AF_INET:
@@ -91,7 +94,8 @@ static inline unsigned int __sel_hash(struct
xfrm_selector *sel, unsigned short
sel->prefixlen_s != 32)
return hmask + 1;
- h = __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
@@ -99,28 +103,30 @@ static inline unsigned int __sel_hash(struct
xfrm_selector *sel, unsigned short
sel->prefixlen_s != 128)
return hmask + 1;
- h = __xfrm6_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
break;
};
- h ^= (h >> 16);
- return h & hmask;
+
+ return jhash_2words(shash, dhash, family) & hmask;
}
static inline unsigned int __addr_hash(xfrm_address_t *daddr,
xfrm_address_t *saddr, unsigned short family, unsigned int hmask)
{
- unsigned int h = 0;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
switch (family) {
case AF_INET:
- h = __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
-
case AF_INET6:
- h = __xfrm6_daddr_saddr_hash(daddr, saddr);
- break;
- };
- h ^= (h >> 16);
- return h & hmask;
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
+ }
+
+ return jhash_2words(shash, dhash, family) & hmask;
}
extern struct hlist_head *xfrm_hash_alloc(unsigned int sz);
--
^ permalink raw reply related
* [PATCH] dccp: missing destroy of percpu counter variable while unload module
From: Wei Yongjun @ 2009-08-05 7:44 UTC (permalink / raw)
To: David Miller, Gerrit Renker; +Cc: dccp, Netdev
percpu counter dccp_orphan_count is init in dccp_init() by
percpu_counter_init() while dccp module is loaded, but the
destroy of it is missing while dccp module is unloaded. We
can get the kernel WARNING about this. Reproduct by the
following commands:
$ modprobe dccp
$ rmmod dccp
$ modprobe dccp
WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c()
Hardware name: VMware Virtual Platform
list_add corruption. next->prev should be prev (c080c0c4), but was (null). (next
=ca7188cc).
Modules linked in: dccp(+) nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc
Pid: 1956, comm: modprobe Not tainted 2.6.31-rc5 #55
Call Trace:
[<c042f8fa>] warn_slowpath_common+0x6a/0x81
[<c053a6cb>] ? __list_add+0x27/0x5c
[<c042f94f>] warn_slowpath_fmt+0x29/0x2c
[<c053a6cb>] __list_add+0x27/0x5c
[<c053c9b3>] __percpu_counter_init+0x4d/0x5d
[<ca9c90c7>] dccp_init+0x19/0x2ed [dccp]
[<c0401141>] do_one_initcall+0x4f/0x111
[<ca9c90ae>] ? dccp_init+0x0/0x2ed [dccp]
[<c06971b5>] ? notifier_call_chain+0x26/0x48
[<c0444943>] ? __blocking_notifier_call_chain+0x45/0x51
[<c04516f7>] sys_init_module+0xac/0x1bd
[<c04028e4>] sysenter_do_call+0x12/0x22
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/dccp/proto.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index 3281013..1bca920 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -1159,6 +1159,7 @@ static void __exit dccp_fini(void)
kmem_cache_destroy(dccp_hashinfo.bind_bucket_cachep);
dccp_ackvec_exit();
dccp_sysctl_exit();
+ percpu_counter_destroy(&dccp_orphan_count);
}
module_init(dccp_init);
--
1.6.2.2
^ permalink raw reply related
* Re: neigh_periodic_timer expires too often
From: Luciano Coelho @ 2009-08-05 7:48 UTC (permalink / raw)
To: ext Eric Dumazet; +Cc: netdev@vger.kernel.org, Kristo Tero (Nokia-D/Tampere)
In-Reply-To: <4A72E8A1.2070705@gmail.com>
ext Eric Dumazet wrote:
> Luciano Coelho a écrit :
>
>> Coelho Luciano (Nokia-D/Helsinki) wrote:
>>
>>> ext Eric Dumazet wrote:
>>>
>>>
>>>> So please test it and tell me/us you like it :)
>>>>
>>>>
>>> I applied your patch on top of the 2.6.28 I'm using and will start
>>> testing it now. I can also try to test it on top of 2.6.31-rc4 plus
>>> wireless-testing stuff, if needed.
>>>
>>> I'll tell you that I liked your patch in a moment (I actually already
>>> liked it, but I'll wait until I know it works before I tell you ;)
>>>
>>>
>> Just a small update. We have run some very basic tests with 2.6.28.
>> The patch seems to work fine and we don't see excessive wake-ups from
>> neigh anymore (thanks Tero for helping with the tests). We will still
>> run one of our full release test rounds in order to make sure that there
>> are no regressions. I'll let you know when we have some more results.
>>
>>
>
> Thanks for the update, I am running this patch on net-next-2.6 with no problem.
>
We have now run our release round tests and everything is working fine.
I'll report back if we find any issues with this change in the future
(which I really don't expect to happen ;).
Thank you very much for fixing this.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] dccp: missing destroy of percpu counter variable while unload module
From: Eric Dumazet @ 2009-08-05 7:59 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, Gerrit Renker, dccp, Netdev
In-Reply-To: <4A793867.3030104@cn.fujitsu.com>
Wei Yongjun a écrit :
> percpu counter dccp_orphan_count is init in dccp_init() by
> percpu_counter_init() while dccp module is loaded, but the
> destroy of it is missing while dccp module is unloaded. We
> can get the kernel WARNING about this. Reproduct by the
> following commands:
>
> $ modprobe dccp
> $ rmmod dccp
> $ modprobe dccp
>
> WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c()
> Hardware name: VMware Virtual Platform
> list_add corruption. next->prev should be prev (c080c0c4), but was (null). (next
> =ca7188cc).
> Modules linked in: dccp(+) nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc
> Pid: 1956, comm: modprobe Not tainted 2.6.31-rc5 #55
> Call Trace:
> [<c042f8fa>] warn_slowpath_common+0x6a/0x81
> [<c053a6cb>] ? __list_add+0x27/0x5c
> [<c042f94f>] warn_slowpath_fmt+0x29/0x2c
> [<c053a6cb>] __list_add+0x27/0x5c
> [<c053c9b3>] __percpu_counter_init+0x4d/0x5d
> [<ca9c90c7>] dccp_init+0x19/0x2ed [dccp]
> [<c0401141>] do_one_initcall+0x4f/0x111
> [<ca9c90ae>] ? dccp_init+0x0/0x2ed [dccp]
> [<c06971b5>] ? notifier_call_chain+0x26/0x48
> [<c0444943>] ? __blocking_notifier_call_chain+0x45/0x51
> [<c04516f7>] sys_init_module+0xac/0x1bd
> [<c04028e4>] sysenter_do_call+0x12/0x22
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> ---
> net/dccp/proto.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/dccp/proto.c b/net/dccp/proto.c
> index 3281013..1bca920 100644
> --- a/net/dccp/proto.c
> +++ b/net/dccp/proto.c
> @@ -1159,6 +1159,7 @@ static void __exit dccp_fini(void)
> kmem_cache_destroy(dccp_hashinfo.bind_bucket_cachep);
> dccp_ackvec_exit();
> dccp_sysctl_exit();
> + percpu_counter_destroy(&dccp_orphan_count);
> }
>
> module_init(dccp_init);
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
This was added by commit dd24c001 (net: Use a percpu_counter for orphan_count)
(Tue Nov 25 21:17:14 2008), so this could be a stable candidate (2.6.29 & 2.6.30)
Thanks Wei
^ permalink raw reply
* Re: [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: Jussi Maki @ 2009-08-05 8:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <ce10d01f0908050041p43c308fav72ac640f665e161f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
Whoops, line wrapping broke the patch, here's it again.
On Wed, Aug 5, 2009 at 10:41 AM, Jussi Mäki<joamaki@gmail.com> wrote:
> Hi,
>
> The current xfrm hash functions perform very poorly when a number of
> policies have the same
> last byte in source and destination addresses.
>
> For example with __xfrm_dst_hash, hmask of 0xfff:
>
> 192.168.0.1-172.16.0.1 hashes to 3258
> 192.168.0.2-172.16.0.2 hashes to 3258
> ... and so on.
>
> This patch addresses the issue by rewriting the xfrm
> hash functions to use the Jenkins' hash function.
[-- Attachment #2: xfrmhash.patch --]
[-- Type: application/octet-stream, Size: 4881 bytes --]
Signed-off-by: Jussi Maki <joamaki@gmail.com>
---
net/xfrm/xfrm_hash.h | 90 ++++++++++++++++++++++++++-----------------------
1 files changed, 48 insertions(+), 42 deletions(-)
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index d401dc8..59d4cb6 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -3,6 +3,7 @@
#include <linux/xfrm.h>
#include <linux/socket.h>
+#include <linux/jhash.h>
static inline unsigned int __xfrm4_addr_hash(xfrm_address_t *addr)
{
@@ -14,31 +15,27 @@ static inline unsigned int __xfrm6_addr_hash(xfrm_address_t *addr)
return ntohl(addr->a6[2] ^ addr->a6[3]);
}
-static inline unsigned int __xfrm4_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
-{
- return ntohl(daddr->a4 ^ saddr->a4);
-}
-
-static inline unsigned int __xfrm6_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
-{
- return ntohl(daddr->a6[2] ^ daddr->a6[3] ^
- saddr->a6[2] ^ saddr->a6[3]);
-}
-
-static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr, xfrm_address_t *saddr,
- u32 reqid, unsigned short family,
+static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr,
+ xfrm_address_t *saddr,
+ u32 reqid,
+ unsigned short family,
unsigned int hmask)
{
- unsigned int h = family ^ reqid;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
+
switch (family) {
case AF_INET:
- h ^= __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_daddr_saddr_hash(daddr, saddr);
- break;
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
}
- return (h ^ (h >> 16)) & hmask;
+
+ return jhash_3words(shash, dhash,
+ reqid, family) & hmask;
}
static inline unsigned __xfrm_src_hash(xfrm_address_t *daddr,
@@ -46,32 +43,37 @@ static inline unsigned __xfrm_src_hash(xfrm_address_t *daddr,
unsigned short family,
unsigned int hmask)
{
- unsigned int h = family;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
switch (family) {
case AF_INET:
- h ^= __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_daddr_saddr_hash(daddr, saddr);
- break;
- };
- return (h ^ (h >> 16)) & hmask;
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
+ }
+ return jhash_2words(shash, dhash, family) & hmask;
}
static inline unsigned int
-__xfrm_spi_hash(xfrm_address_t *daddr, __be32 spi, u8 proto, unsigned short family,
+__xfrm_spi_hash(xfrm_address_t *daddr, __be32 spi, u8 proto,
+ unsigned short family,
unsigned int hmask)
{
- unsigned int h = (__force u32)spi ^ proto;
+ unsigned int h;
+
switch (family) {
case AF_INET:
- h ^= __xfrm4_addr_hash(daddr);
+ h = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_addr_hash(daddr);
+ h = __xfrm6_addr_hash(daddr);
break;
}
- return (h ^ (h >> 10) ^ (h >> 20)) & hmask;
+
+ return jhash_3words(h, spi, proto, family) & hmask;
}
static inline unsigned int __idx_hash(u32 index, unsigned int hmask)
@@ -83,7 +85,8 @@ static inline unsigned int __sel_hash(struct xfrm_selector *sel, unsigned short
{
xfrm_address_t *daddr = &sel->daddr;
xfrm_address_t *saddr = &sel->saddr;
- unsigned int h = 0;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
switch (family) {
case AF_INET:
@@ -91,7 +94,8 @@ static inline unsigned int __sel_hash(struct xfrm_selector *sel, unsigned short
sel->prefixlen_s != 32)
return hmask + 1;
- h = __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
@@ -99,28 +103,30 @@ static inline unsigned int __sel_hash(struct xfrm_selector *sel, unsigned short
sel->prefixlen_s != 128)
return hmask + 1;
- h = __xfrm6_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
break;
};
- h ^= (h >> 16);
- return h & hmask;
+
+ return jhash_2words(shash, dhash, family) & hmask;
}
static inline unsigned int __addr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr, unsigned short family, unsigned int hmask)
{
- unsigned int h = 0;
+ unsigned int shash = 0;
+ unsigned int dhash = 0;
switch (family) {
case AF_INET:
- h = __xfrm4_daddr_saddr_hash(daddr, saddr);
+ shash = __xfrm4_addr_hash(saddr);
+ dhash = __xfrm4_addr_hash(daddr);
break;
-
case AF_INET6:
- h = __xfrm6_daddr_saddr_hash(daddr, saddr);
- break;
- };
- h ^= (h >> 16);
- return h & hmask;
+ shash = __xfrm6_addr_hash(saddr);
+ dhash = __xfrm6_addr_hash(daddr);
+ }
+
+ return jhash_2words(shash, dhash, family) & hmask;
}
extern struct hlist_head *xfrm_hash_alloc(unsigned int sz);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/2] net: implement a SO_PROTOCOL getsockoption
From: Jan Engelhardt @ 2009-08-05 8:45 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev@vger.kernel.org
In-Reply-To: <200908050935.03272.remi.denis-courmont@nokia.com>
On Wednesday 2009-08-05 08:35, Rémi Denis-Courmont wrote:
>On Tuesday 04 August 2009 20:28:28 ext Jan Engelhardt wrote:
>> Similar to SO_TYPE returning the socket type, SO_PROTOCOL allows to
>> retrieve the protocol used with a given socket.
>
>You can easily infer the protocol family from the address family from
>getsockname().
As far as I remember, what you can get from getsockname is the
domain type (AF_*/PF_*) through struct sockaddr->sa_family.
Did you mean that?
Though SO_PROTOCOL and SO_DOMAIN go nicely along with SO_TYPE.
^ permalink raw reply
* Re: [PATCH] net: Fix spinlock use in alloc_netdev_mq()
From: Jiri Pirko @ 2009-08-05 8:47 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Miller, Peter Zijlstra, torvalds, akpm, netdev,
linux-kernel
In-Reply-To: <20090805071658.GA14073@elte.hu>
Wed, Aug 05, 2009 at 09:16:58AM CEST, mingo@elte.hu wrote:
>
>From 6a0405d0e9b5e15bb81b8278b08fdb931a6e8837 Mon Sep 17 00:00:00 2001
>From: Ingo Molnar <mingo@elte.hu>
>Date: Wed, 5 Aug 2009 09:14:11 +0200
>Subject: [PATCH] net: Fix spinlock use in alloc_netdev_mq()
>
>-tip testing found this lockdep warning:
>
>[ 2.272010] calling net_dev_init+0x0/0x164 @ 1
>[ 2.276033] device class 'net': registering
>[ 2.280191] INFO: trying to register non-static key.
>[ 2.284005] the code is fine but needs lockdep annotation.
>[ 2.284005] turning off the locking correctness validator.
>[ 2.284005] Pid: 1, comm: swapper Not tainted 2.6.31-rc5-tip #1145
>[ 2.284005] Call Trace:
>[ 2.284005] [<7958eb4e>] ? printk+0xf/0x11
>[ 2.284005] [<7904f83c>] __lock_acquire+0x11b/0x622
>[ 2.284005] [<7908c9b7>] ? alloc_debug_processing+0xf9/0x144
>[ 2.284005] [<7904e2be>] ? mark_held_locks+0x3a/0x52
>[ 2.284005] [<7908dbc4>] ? kmem_cache_alloc+0xa8/0x13f
>[ 2.284005] [<7904e475>] ? trace_hardirqs_on_caller+0xa2/0xc3
>[ 2.284005] [<7904fdf6>] lock_acquire+0xb3/0xd0
>[ 2.284005] [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
>[ 2.284005] [<79591514>] _spin_lock_bh+0x2d/0x5d
>[ 2.284005] [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
>[ 2.284005] [<79489678>] alloc_netdev_mq+0xf5/0x1ad
>[ 2.284005] [<793a38f2>] ? loopback_setup+0x0/0x74
>[ 2.284005] [<798eecd0>] loopback_net_init+0x20/0x5d
>[ 2.284005] [<79483efb>] register_pernet_device+0x23/0x4b
>[ 2.284005] [<798f5c9f>] net_dev_init+0x115/0x164
>[ 2.284005] [<7900104f>] do_one_initcall+0x4a/0x11a
>[ 2.284005] [<798f5b8a>] ? net_dev_init+0x0/0x164
>[ 2.284005] [<79066f6d>] ? register_irq_proc+0x8c/0xa8
>[ 2.284005] [<798cc29a>] do_basic_setup+0x42/0x52
>[ 2.284005] [<798cc30a>] kernel_init+0x60/0xa1
>[ 2.284005] [<798cc2aa>] ? kernel_init+0x0/0xa1
>[ 2.284005] [<79003e03>] kernel_thread_helper+0x7/0x10
>[ 2.284078] device: 'lo': device_add
>[ 2.288248] initcall net_dev_init+0x0/0x164 returned 0 after 11718 usecs
>[ 2.292010] calling neigh_init+0x0/0x66 @ 1
>[ 2.296010] initcall neigh_init+0x0/0x66 returned 0 after 0 usecs
>
>it's using an zero-initialized spinlock. This is a side-effect of:
>
> dev_unicast_init(dev);
>
>in alloc_netdev_mq() making use of dev->addr_list_lock.
>
>The device has just been allocated freshly, it's not accessible
>anywhere yet so no locking is needed at all - in fact it's wrong
>to lock it here (the lock isnt initialized yet).
Yes this looks like the right approach. Sorry for this bug :(
>
>This bug was introduced via:
>
>| commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
>| Date: Thu Jul 30 01:06:12 2009 +0000
>|
>| net: restore the original spinlock to protect unicast list
>
>Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Jiri Pirko <jpirko@redhat.com>
>---
> net/core/dev.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
>diff --git a/net/core/dev.c b/net/core/dev.c
>index 43e61ba..6a94475 100644
>--- a/net/core/dev.c
>+++ b/net/core/dev.c
>@@ -4007,9 +4007,7 @@ static void dev_unicast_flush(struct net_device *dev)
>
> static void dev_unicast_init(struct net_device *dev)
> {
>- netif_addr_lock_bh(dev);
> __hw_addr_init(&dev->uc);
>- netif_addr_unlock_bh(dev);
> }
>
>
^ permalink raw reply
* Re: [PATCH 1/2] net: implement a SO_PROTOCOL getsockoption
From: Rémi Denis-Courmont @ 2009-08-05 9:28 UTC (permalink / raw)
To: ext Jan Engelhardt; +Cc: netdev@vger.kernel.org
In-Reply-To: <alpine.LSU.2.00.0908051042180.28374@fbirervta.pbzchgretzou.qr>
On Wednesday 05 August 2009 11:45:29 ext Jan Engelhardt wrote:
> On Wednesday 2009-08-05 08:35, Rémi Denis-Courmont wrote:
> >On Tuesday 04 August 2009 20:28:28 ext Jan Engelhardt wrote:
> >> Similar to SO_TYPE returning the socket type, SO_PROTOCOL allows to
> >> retrieve the protocol used with a given socket.
> >
> >You can easily infer the protocol family from the address family from
> >getsockname().
>
> As far as I remember, what you can get from getsockname is the
> domain type (AF_*/PF_*) through struct sockaddr->sa_family.
> Did you mean that?
Yes. It's almost like SO_DOMAIN but more portable and uglier.
> Though SO_PROTOCOL and SO_DOMAIN go nicely along with SO_TYPE.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* BUG: spinlock bad magic on CPU#1, swapper/1
From: Frans Pop @ 2009-08-05 9:36 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: netdev
Current v2.6.31-rc5-246-g90bc1a6 gives me:
BUG: spinlock bad magic on CPU#1, swapper/1
lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
Call Trace:
[<ffffffff811345e8>] spin_bug+0xa2/0xaa
[<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
[<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
[<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
[<ffffffff81433487>] ? netdev_init+0x6a/0xac
[<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
[<ffffffff8142e718>] loopback_net_init+0x30/0x7a
[<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
[<ffffffff814336bd>] net_dev_init+0x13d/0x19b
[<ffffffff81433580>] ? net_dev_init+0x0/0x19b
[<ffffffff8100905c>] do_one_initcall+0x56/0x12b
[<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
[<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
[<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
[<ffffffff8100ca7a>] child_rip+0xa/0x20
[<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
[<ffffffff8100ca70>] ? child_rip+0x0/0x20
Error occurs during early boot (between PCI/ACPI init and PnP init).
.31-rc5 itself did not give that error.
Cheers,
FJP
^ permalink raw reply
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Frans Pop @ 2009-08-05 9:50 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: netdev, Jiri Pirko
In-Reply-To: <200908051136.44908.elendil@planet.nl>
On Wednesday 05 August 2009, Frans Pop wrote:
> Current v2.6.31-rc5-246-g90bc1a6 gives me:
>
> BUG: spinlock bad magic on CPU#1, swapper/1
> lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
> Call Trace:
> [<ffffffff811345e8>] spin_bug+0xa2/0xaa
> [<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
> [<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
> [<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
> [<ffffffff81433487>] ? netdev_init+0x6a/0xac
> [<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
> [<ffffffff8142e718>] loopback_net_init+0x30/0x7a
> [<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
> [<ffffffff814336bd>] net_dev_init+0x13d/0x19b
> [<ffffffff81433580>] ? net_dev_init+0x0/0x19b
> [<ffffffff8100905c>] do_one_initcall+0x56/0x12b
> [<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
> [<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
> [<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
> [<ffffffff8100ca7a>] child_rip+0xa/0x20
> [<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
>
> Error occurs during early boot (between PCI/ACPI init and PnP init).
Reverting the following commit fixes it:
commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
Author: Jiri Pirko <jpirko@redhat.com>
Date: Thu Jul 30 01:06:12 2009 +0000
net: restore the original spinlock to protect unicast list
There is a path when an assetion in dev_unicast_sync() appears.
igmp6_group_added -> dev_mc_add -> __dev_set_rx_mode ->
-> vlan_dev_set_rx_mode -> dev_unicast_sync
Therefore we cannot protect this list with rtnl. This patch restores the
original protecting this list with spinlock.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Eric Dumazet @ 2009-08-05 10:02 UTC (permalink / raw)
To: Frans Pop; +Cc: Linux Kernel Mailing List, netdev, Jiri Pirko
In-Reply-To: <200908051150.53301.elendil@planet.nl>
Frans Pop a écrit :
> On Wednesday 05 August 2009, Frans Pop wrote:
>> Current v2.6.31-rc5-246-g90bc1a6 gives me:
>>
>> BUG: spinlock bad magic on CPU#1, swapper/1
>> lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>> Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
>> Call Trace:
>> [<ffffffff811345e8>] spin_bug+0xa2/0xaa
>> [<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
>> [<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
>> [<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
>> [<ffffffff81433487>] ? netdev_init+0x6a/0xac
>> [<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
>> [<ffffffff8142e718>] loopback_net_init+0x30/0x7a
>> [<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
>> [<ffffffff814336bd>] net_dev_init+0x13d/0x19b
>> [<ffffffff81433580>] ? net_dev_init+0x0/0x19b
>> [<ffffffff8100905c>] do_one_initcall+0x56/0x12b
>> [<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
>> [<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
>> [<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
>> [<ffffffff8100ca7a>] child_rip+0xa/0x20
>> [<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
>> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
>>
>> Error occurs during early boot (between PCI/ACPI init and PnP init).
>
> Reverting the following commit fixes it:
> commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
> Author: Jiri Pirko <jpirko@redhat.com>
> Date: Thu Jul 30 01:06:12 2009 +0000
>
> net: restore the original spinlock to protect unicast list
>
> There is a path when an assetion in dev_unicast_sync() appears.
>
> igmp6_group_added -> dev_mc_add -> __dev_set_rx_mode ->
> -> vlan_dev_set_rx_mode -> dev_unicast_sync
>
> Therefore we cannot protect this list with rtnl. This patch restores the
> original protecting this list with spinlock.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Tested-by: Meelis Roos <mroos@linux.ee>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> --
Ingo posted a fix
http://marc.info/?l=linux-kernel&m=124945666109347&w=2
^ permalink raw reply
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Jiri Pirko @ 2009-08-05 10:03 UTC (permalink / raw)
To: Frans Pop; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <200908051150.53301.elendil@planet.nl>
Wed, Aug 05, 2009 at 11:50:52AM CEST, elendil@planet.nl wrote:
>On Wednesday 05 August 2009, Frans Pop wrote:
>> Current v2.6.31-rc5-246-g90bc1a6 gives me:
>>
>> BUG: spinlock bad magic on CPU#1, swapper/1
>> lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>> Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
>> Call Trace:
>> [<ffffffff811345e8>] spin_bug+0xa2/0xaa
>> [<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
>> [<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
>> [<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
>> [<ffffffff81433487>] ? netdev_init+0x6a/0xac
>> [<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
>> [<ffffffff8142e718>] loopback_net_init+0x30/0x7a
>> [<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
>> [<ffffffff814336bd>] net_dev_init+0x13d/0x19b
>> [<ffffffff81433580>] ? net_dev_init+0x0/0x19b
>> [<ffffffff8100905c>] do_one_initcall+0x56/0x12b
>> [<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
>> [<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
>> [<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
>> [<ffffffff8100ca7a>] child_rip+0xa/0x20
>> [<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
>> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
>>
>> Error occurs during early boot (between PCI/ACPI init and PnP init).
>
>Reverting the following commit fixes it:
Sure it fixes it but it also exposes the previous bug. I would rather suggest
to go with Ingo's patch.
Jirka
>commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
>Author: Jiri Pirko <jpirko@redhat.com>
>Date: Thu Jul 30 01:06:12 2009 +0000
>
> net: restore the original spinlock to protect unicast list
>
> There is a path when an assetion in dev_unicast_sync() appears.
>
> igmp6_group_added -> dev_mc_add -> __dev_set_rx_mode ->
> -> vlan_dev_set_rx_mode -> dev_unicast_sync
>
> Therefore we cannot protect this list with rtnl. This patch restores the
> original protecting this list with spinlock.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Tested-by: Meelis Roos <mroos@linux.ee>
> Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Frans Pop @ 2009-08-05 10:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Mailing List, netdev, Jiri Pirko
In-Reply-To: <4A7958D3.40206@gmail.com>
On Wednesday 05 August 2009, Eric Dumazet wrote:
> Ingo posted a fix
> http://marc.info/?l=linux-kernel&m=124945666109347&w=2
Thanks. I'd missed that mail.
^ permalink raw reply
* [net-next-2.6 PATCH] be2net:Patch to perform function reset at initialization
From: Sarveshwar Bandi @ 2009-08-05 11:39 UTC (permalink / raw)
To: davem; +Cc: netdev
This patch is a bug fix to avoid system going into a bad state when driver
is loaded in context of kdump kernel. The patch fixes the issue by performing
a soft reset of pci function at probe time.
Signed-off-by: sarveshwarb <sarveshwarb@serverengines.com>
---
drivers/net/benet/be_cmds.c | 21 +++++++++++++++++++++
drivers/net/benet/be_cmds.h | 2 ++
drivers/net/benet/be_main.c | 4 ++++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index de10773..2547ee2 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1019,3 +1019,24 @@ int be_cmd_query_fw_cfg(struct be_adapte
spin_unlock(&adapter->mbox_lock);
return status;
}
+
+int be_cmd_reset_function(struct be_adapter *adapter)
+{
+ struct be_mcc_wrb *wrb = wrb_from_mbox(&adapter->mbox_mem);
+ struct be_cmd_req_hdr *req = embedded_payload(wrb);
+ int status;
+
+ spin_lock(&adapter->mbox_lock);
+
+ memset(wrb, 0, sizeof(*wrb));
+
+ be_wrb_hdr_prepare(wrb, sizeof(*req), true, 0);
+
+ be_cmd_hdr_prepare(req, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_FUNCTION_RESET, sizeof(*req));
+
+ status = be_mbox_notify(adapter);
+
+ spin_unlock(&adapter->mbox_lock);
+ return status;
+}
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 5c5de35..7061806 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -135,6 +135,7 @@ #define OPCODE_COMMON_EQ_DESTROY
#define OPCODE_COMMON_QUERY_FIRMWARE_CONFIG 58
#define OPCODE_COMMON_NTWK_PMAC_ADD 59
#define OPCODE_COMMON_NTWK_PMAC_DEL 60
+#define OPCODE_COMMON_FUNCTION_RESET 61
#define OPCODE_ETH_ACPI_CONFIG 2
#define OPCODE_ETH_PROMISCUOUS 3
@@ -744,4 +745,5 @@ extern int be_cmd_set_flow_control(struc
extern int be_cmd_get_flow_control(struct be_adapter *adapter,
u32 *tx_fc, u32 *rx_fc);
extern int be_cmd_query_fw_cfg(struct be_adapter *adapter, u32 *port_num);
+extern int be_cmd_reset_function(struct be_adapter *adapter);
extern void be_process_mcc(struct be_adapter *adapter);
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index ef82a52..d20235b 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1873,6 +1873,10 @@ static int __devinit be_probe(struct pci
if (status)
goto free_netdev;
+ status = be_cmd_reset_function(adapter);
+ if (status)
+ goto ctrl_clean;
+
status = be_stats_init(adapter);
if (status)
goto ctrl_clean;
--
1.4.0
^ permalink raw reply related
* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-05 12:14 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <4A78CA13.6040409@ring3k.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike McCormack wrote:
>> Again, any hints would be greatly appreciated (and sorry for being
>> persistent about this annoying little bug...).
>
> Thanks for being persistent in testing :-) Looks like you've got a
> fairly unusual piece of hardware, as Stephen indicated.
Indeed, although I didn't think it _that_ unusual. It's just a 19" rack
appliance with 2 expansion slots for 4x LAN ports each. And those are
based around sky2.
But we have had problems before with kernel 2.4.34/.36 as well with that
hardware. They just weren't as easily reproducible but manifested
themselves in occasional malfunctions of the network devices that could
be solved by an ifdown/ifup cycle.
We still have one spare box and will try that one in case the hardware
is really flaky (which would be strange, given how reproducible it is
right now).
> Would you mind adding the phy_lock fix on top of the latest net-2.6
> git version of sky2 and testing that?
Tried it, doesn't fix the issue.
What would be the simplest change to stop disabling phy when the last
device goes down?
best regards,
Rene
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp5d6AACgkQq7SPDcPCS95OuACggTuTHsZd7m6IqHt0mrqUZbju
G4wAoPfPGr5G05E6HdO9kcKflGaSx7f5
=78yk
-----END PGP SIGNATURE-----
^ 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