* Re: kernel panic with time-stamping in phy devices (monitor mode)
From: Eric Dumazet @ 2010-12-06 4:50 UTC (permalink / raw)
To: Changli Gao; +Cc: netdev, Richard Cochran, Andrew Watts, David Miller, stable
In-Reply-To: <AANLkTinFEUd5vuBu98COXMRGMFcpwtu_dsw=_=cN6oZJ@mail.gmail.com>
Le lundi 06 décembre 2010 à 08:01 +0800, Changli Gao a écrit :
> How about using skb_headroom(skb) < ETH_HLEN ?
>
Yes, good idea, thanks !
[PATCH net-2.6] net: fix skb_defer_rx_timestamp()
After commit c1f19b51d1d8 (net: support time stamping in phy devices.),
kernel might crash if CONFIG_NETWORK_PHY_TIMESTAMPING=y and
skb_defer_rx_timestamp() handles a packet without an ethernet header.
Fixes kernel bugzilla #24102
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=24102
Reported-and-tested-by: Andrew Watts <akwatts@ymail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Changli Gao <xiaosuo@gmail.com>
Cc: stable@kernel.org
---
net/core/timestamping.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/timestamping.c b/net/core/timestamping.c
index 0ae6c22..c19bb4e 100644
--- a/net/core/timestamping.c
+++ b/net/core/timestamping.c
@@ -96,11 +96,13 @@ bool skb_defer_rx_timestamp(struct sk_buff *skb)
struct phy_device *phydev;
unsigned int type;
- skb_push(skb, ETH_HLEN);
+ if (skb_headroom(skb) < ETH_HLEN)
+ return false;
+ __skb_push(skb, ETH_HLEN);
type = classify(skb);
- skb_pull(skb, ETH_HLEN);
+ __skb_pull(skb, ETH_HLEN);
switch (type) {
case PTP_CLASS_V1_IPV4:
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply related
* Re: [PATCH] net/r8169: Remove the firmware of RTL8111D
From: Ben Hutchings @ 2010-12-06 4:38 UTC (permalink / raw)
To: Francois Romieu; +Cc: Hayes Wang, netdev, linux-kernel
In-Reply-To: <20101201080732.GA3234@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
On Wed, 2010-12-01 at 09:07 +0100, Francois Romieu wrote:
> Hayes Wang <hayeswang@realtek.com> :
> > Remove the firmware of RTL8111D from the kernel.
> > The binary file of firmware would be moved to linux-firmware repository.
>
> The driver can not simply go along when request_firmware fails. Though Ben's
> code did not take care of it, the driver should imho propagate some return
> code. Ben ?
[...]
Sorry I haven't been more responsive on this.
I have reports that the RTL8111D/8168D hardware can work without this
firmware, possibly with limited functionality or compatibility. (I
assume it is a patch for the original firmware loaded from ROM or
flash.) So I feel obliged to give users the choice to use the driver
without installing non-free firmware. If you want to make the warning
on failure of request_firmware() more explicit then that's OK with me.
If you make the failure fatal I will probably revert that in Debian.
Ben.
--
Ben Hutchings, Debian Developer and kernel team member
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* echo > 0 .../disable_ipv6 broken in 2.6.37-rc4
From: Eric W. Biederman @ 2010-12-06 0:24 UTC (permalink / raw)
To: netdev; +Cc: Brian Haley, Mahesh Kelkar, Lorenzo Colitti
In 2.6.37-rc4 ipv6 can be disabled not enabled.
The last kernel I have tested and know this works on is 2.6.33.
To reproduce:
~ # ip link set lo up
~ # ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.026 ms
^C
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 782ms
rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms
~ # echo 1 > /proc/sys/net/ipv6/conf/lo/disable_ipv6
~ # ping6 ::1
connect: Network is unreachable
~ # echo 0 > /proc/sys/net/ipv6/conf/lo/disable_ipv6
~ # ping6 ::1
connect: Network is unreachable
I intend to poke at this a little more but at the moment
I am drawing a blank at what is going on.
I have tried reverting the last change to the ipv6 logic
and that doesn't make a difference.
commit 64e724f62ab743d55229cd5e27ec8b068b68eb16
Author: Brian Haley <brian.haley@hp.com>
Date: Tue Jul 20 10:34:30 2010 +0000
ipv6: Don't add routes to ipv6 disabled interfaces.
If the interface has IPv6 disabled, don't add a multicast or
link-local route since we won't be adding a link-local address.
Reported-by: Mahesh Kelkar <maheshkelkar@gmail.com>
Signed-off-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I intend to keep poking at this but if anyone can figure this out
before I do I would be greatly appreciative.
Eric
^ permalink raw reply
* Re: echo > 0 .../disable_ipv6 broken in 2.6.37-rc4
From: Eric W. Biederman @ 2010-12-06 0:39 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: netdev, Brian Haley, Mahesh Kelkar
In-Reply-To: <AANLkTin4hO63J4thByJeG2SiGHn9ZqsbWKy1p_TEfeu_@mail.gmail.com>
Lorenzo Colitti <lorenzo@google.com> writes:
> On Sun, Dec 5, 2010 at 4:24 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> In 2.6.37-rc4 ipv6 can be disabled not enabled.
>> The last kernel I have tested and know this works on is 2.6.33.
>
> I'm pretty sure I could successfully re-enable IPv6 on non-loopback
> interfaces (wlan0, eth0) on net-2.6 pulled a little after 2.6.37-rc1.
> I didn't try lo though. Does re-enabling IPv6 on a "real" interface
> still work?
Interesting that case seems to work.
Eric
^ permalink raw reply
* Re: echo > 0 .../disable_ipv6 broken in 2.6.37-rc4
From: Lorenzo Colitti @ 2010-12-06 0:33 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, Brian Haley, Mahesh Kelkar
In-Reply-To: <m17hfnlpe1.fsf@fess.ebiederm.org>
On Sun, Dec 5, 2010 at 4:24 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> In 2.6.37-rc4 ipv6 can be disabled not enabled.
> The last kernel I have tested and know this works on is 2.6.33.
I'm pretty sure I could successfully re-enable IPv6 on non-loopback
interfaces (wlan0, eth0) on net-2.6 pulled a little after 2.6.37-rc1.
I didn't try lo though. Does re-enabling IPv6 on a "real" interface
still work?
^ permalink raw reply
* Re: kernel panic with time-stamping in phy devices (monitor mode)
From: Changli Gao @ 2010-12-06 0:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Watts, Richard Cochran, netdev, David Miller, stable
In-Reply-To: <1291551879.2806.253.camel@edumazet-laptop>
On Sun, Dec 5, 2010 at 8:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le samedi 04 décembre 2010 à 12:46 -0800, Andrew Watts a écrit :
>
>> Eric, I echo the thanks on the lightning patch.
>> Impressive turnaround!
>>
>> There's an open bug report on the kernel's bugzilla
>> for 2.6.36 (#24102). What is the best way to tie these
>> together?
>
> Thanks Andy, here is the official patch submission I am going to make.
>
> [PATCH net-2.6] net: fix skb_defer_rx_timestamp()
>
> After commit c1f19b51d1d8 (net: support time stamping in phy devices.),
> kernel might crash if CONFIG_NETWORK_PHY_TIMESTAMPING=y and
> skb_defer_rx_timestamp() handles a packet without an ethernet header.
>
> Fixes kernel bugzilla #24102
>
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=24102
> Reported-and-tested-by: Andrew Watts <akwatts@ymail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: stable@kernel.org
> ---
> net/core/timestamping.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/timestamping.c b/net/core/timestamping.c
> index 0ae6c22..c4fbf85 100644
> --- a/net/core/timestamping.c
> +++ b/net/core/timestamping.c
> @@ -96,11 +96,13 @@ bool skb_defer_rx_timestamp(struct sk_buff *skb)
> struct phy_device *phydev;
> unsigned int type;
>
> - skb_push(skb, ETH_HLEN);
> + if (skb->data - ETH_HLEN < skb->head)
> + return false;
How about using skb_headroom(skb) < ETH_HLEN ?
And I checked the code of skb_push(). If the headroom of a skb is less
than the requested, Linux will panic with a message titled
"skb_under_panic()". But I can't find this info in the Oops. Maybe the
Oops isn't complete.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] netfilter: fix the race when initializing nf_ct_expect_hash_rnd
From: Changli Gao @ 2010-12-05 16:26 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, David S. Miller, netdev, Changli Gao
Since nf_ct_expect_dst_hash() may be called without nf_conntrack_lock
locked, nf_ct_expect_hash_rnd should be initialized in the atomic way.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/netfilter/nf_conntrack_expect.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/nf_conntrack_expect.c b/net/netfilter/nf_conntrack_expect.c
index 46e8966..e2bb3ef 100644
--- a/net/netfilter/nf_conntrack_expect.c
+++ b/net/netfilter/nf_conntrack_expect.c
@@ -34,7 +34,6 @@ EXPORT_SYMBOL_GPL(nf_ct_expect_hsize);
static unsigned int nf_ct_expect_hash_rnd __read_mostly;
unsigned int nf_ct_expect_max __read_mostly;
-static int nf_ct_expect_hash_rnd_initted __read_mostly;
static struct kmem_cache *nf_ct_expect_cachep __read_mostly;
@@ -77,10 +76,13 @@ static unsigned int nf_ct_expect_dst_hash(const struct nf_conntrack_tuple *tuple
{
unsigned int hash;
- if (unlikely(!nf_ct_expect_hash_rnd_initted)) {
- get_random_bytes(&nf_ct_expect_hash_rnd,
- sizeof(nf_ct_expect_hash_rnd));
- nf_ct_expect_hash_rnd_initted = 1;
+ if (unlikely(!nf_ct_expect_hash_rnd)) {
+ unsigned int rand;
+
+ do {
+ get_random_bytes(&rand, sizeof(rand));
+ } while (!rand);
+ cmpxchg(&nf_ct_expect_hash_rnd, 0, rand);
}
hash = jhash2(tuple->dst.u3.all, ARRAY_SIZE(tuple->dst.u3.all),
^ permalink raw reply related
* Re: qlge warning
From: Ron Mercer @ 2010-12-05 22:27 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Yinghai Lu, David Miller, NetDev, Ingo Molnar, Linux Driver
In-Reply-To: <4CF95995.1070506@gmail.com>
OK, I see the point. We are working on it.
Thanks
On Fri, Dec 03, 2010 at 12:56:53PM -0800, Jarek Poplawski wrote:
> It looks like cancel_delayed_work_sync in ql_adapter_down is illegal.
> We can't sync works with rtnl_lock while holding it in qlge_close.
>
> Maintainers CC'ed.
>
> Jarek P.
>
> Yinghai Lu wrote:
> > [ 290.233264] =======================================================
> > [ 290.251780] [ INFO: possible circular locking dependency detected ]
> > [ 290.271534] 2.6.37-rc4-tip-yh-05919-geb30094-dirty #308
> > [ 290.271775] -------------------------------------------------------
> > [ 290.291512] swapper/1 is trying to acquire lock:
> > [ 290.291725] ((&(&qdev->mpi_port_cfg_work)->work)){+.+...}, at:
> > [<ffffffff81096419>] wait_on_work+0x0/0xff
> > [ 290.311643]
> > [ 290.311644] but task is already holding lock:
> > [ 290.311915] (rtnl_mutex){+.+.+.}, at: [<ffffffff81bb094d>]
> > rtnl_lock+0x17/0x19
> > [ 290.331681]
> > [ 290.331682] which lock already depends on the new lock.
> > [ 290.331684]
> > [ 290.351491]
> > [ 290.351492] the existing dependency chain (in reverse order) is:
> > [ 290.351830]
> > [ 290.351831] -> #1 (rtnl_mutex){+.+.+.}:
> > [ 290.371562] [<ffffffff810ae6b6>] lock_acquire+0xca/0xf0
> > [ 290.371824] [<ffffffff81cdbf5d>] mutex_lock_nested+0x60/0x2b8
> > [ 290.391539] [<ffffffff81bb094d>] rtnl_lock+0x17/0x19
> > [ 290.411250] [<ffffffff818501ad>] ql_mpi_port_cfg_work+0x1f/0x1ad
> > [ 290.411606] [<ffffffff81095189>] process_one_work+0x234/0x3e8
> > [ 290.431282] [<ffffffff81095663>] worker_thread+0x17f/0x261
> > [ 290.431583] [<ffffffff8109a633>] kthread+0xa0/0xa8
> > [ 290.451279] [<ffffffff8103a914>] kernel_thread_helper+0x4/0x10
> > [ 290.451581]
> > [ 290.451582] -> #0 ((&(&qdev->mpi_port_cfg_work)->work)){+.+...}:
> > [ 290.471483] [<ffffffff810ada85>] __lock_acquire+0x113c/0x1813
> > [ 290.491177] [<ffffffff810ae6b6>] lock_acquire+0xca/0xf0
> > [ 290.491451] [<ffffffff8109646c>] wait_on_work+0x53/0xff
> > [ 290.511128] [<ffffffff810965da>] __cancel_work_timer+0xc2/0x102
> > [ 290.511434] [<ffffffff8109662c>] cancel_delayed_work_sync+0x12/0x14
> > [ 290.531233] [<ffffffff81847646>] ql_cancel_all_work_sync+0x64/0x68
> > [ 290.531563] [<ffffffff818499d5>] ql_adapter_down+0x23/0xf6
> > [ 290.551298] [<ffffffff81849ca7>] qlge_close+0x67/0x76
> > [ 290.571015] [<ffffffff81ba3853>] __dev_close+0x7b/0x89
> > [ 290.571297] [<ffffffff81ba5535>] __dev_change_flags+0xad/0x131
> > [ 290.590974] [<ffffffff81ba563a>] dev_change_flags+0x21/0x57
> > [ 290.591280] [<ffffffff827de30e>] ic_close_devs+0x2e/0x48
> > [ 290.610978] [<ffffffff827df332>] ip_auto_config+0xbc9/0xe84
> > [ 290.611280] [<ffffffff810002da>] do_one_initcall+0x57/0x135
> > [ 290.630977] [<ffffffff8278ef8a>] kernel_init+0x16c/0x1f6
> > [ 290.631263] [<ffffffff8103a914>] kernel_thread_helper+0x4/0x10
> > [ 290.651000]
> > [ 290.651001] other info that might help us debug this:
> > [ 290.651003]
> > [ 290.670829] 1 lock held by swapper/1:
> > [ 290.671013] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff81bb094d>]
> > rtnl_lock+0x17/0x19
> > [ 290.690819]
> > [ 290.690820] stack backtrace:
> > [ 290.691054] Pid: 1, comm: swapper Not tainted
> > 2.6.37-rc4-tip-yh-05919-geb30094-dirty #308
> > [ 290.710805] Call Trace:
> > [ 290.710938] [<ffffffff810aa296>] ? print_circular_bug+0xaf/0xbe
> > [ 290.730683] [<ffffffff810ada85>] ? __lock_acquire+0x113c/0x1813
> > [ 290.730955] [<ffffffff81095d70>] ? wait_on_cpu_work+0xdb/0x114
> > [ 290.750672] [<ffffffff81096419>] ? wait_on_work+0x0/0xff
> > [ 290.750939] [<ffffffff810ae6b6>] ? lock_acquire+0xca/0xf0
> > [ 290.770664] [<ffffffff81096419>] ? wait_on_work+0x0/0xff
> > [ 290.770920] [<ffffffff8109646c>] ? wait_on_work+0x53/0xff
> > [ 290.790575] [<ffffffff81096419>] ? wait_on_work+0x0/0xff
> > [ 290.790821] [<ffffffff810965da>] ? __cancel_work_timer+0xc2/0x102
> > [ 290.810559] [<ffffffff8109662c>] ? cancel_delayed_work_sync+0x12/0x14
> > [ 290.810855] [<ffffffff81847646>] ? ql_cancel_all_work_sync+0x64/0x68
> > [ 290.830594] [<ffffffff818499d5>] ? ql_adapter_down+0x23/0xf6
> > [ 290.830867] [<ffffffff81849ca7>] ? qlge_close+0x67/0x76
> > [ 290.850568] [<ffffffff81ba3853>] ? __dev_close+0x7b/0x89
> > [ 290.850829] [<ffffffff81ba5535>] ? __dev_change_flags+0xad/0x131
> > [ 290.870540] [<ffffffff81ba563a>] ? dev_change_flags+0x21/0x57
> > [ 290.870815] [<ffffffff827de30e>] ? ic_close_devs+0x2e/0x48
> > [ 290.890595] [<ffffffff827df332>] ? ip_auto_config+0xbc9/0xe84
> > [ 290.910247] [<ffffffff81cda1e3>] ? printk+0x41/0x43
> > [ 290.910488] [<ffffffff827de769>] ? ip_auto_config+0x0/0xe84
> > [ 290.910747] [<ffffffff810002da>] ? do_one_initcall+0x57/0x135
> > [ 290.930455] [<ffffffff8278ef8a>] ? kernel_init+0x16c/0x1f6
> > [ 290.930743] [<ffffffff8103a914>] ? kernel_thread_helper+0x4/0x10
> > [ 290.950419] [<ffffffff81cde23c>] ? restore_args+0x0/0x30
> > [ 290.970152] [<ffffffff8278ee1e>] ? kernel_init+0x0/0x1f6
> > [ 290.970398] [<ffffffff8103a910>] ? kernel_thread_helper+0x0/0x10
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
^ permalink raw reply
* weird network problem - stalls, reload works
From: Michael Tokarev @ 2010-12-05 22:52 UTC (permalink / raw)
To: netdev
Hello.
I've a weird networking problem here, which I'm
trying to hunt for some time.
Small LAN, just 3 machines and a server, all in
single small room, all connected to a 100Mbps switch.
Sometimes, network between the (linux) server and
workstations just stops. It may happen after
transferring a few megabytes of data (rare), or
whole thing may work for several days or even
weeks in a row, but end result is the same: at
some point it stalls.
Reloading the interface in question, like this:
ifdown eth0; sleep 2; ifup eth0
restores the network back, till it breaks again.
Note here that, say, sleep 1 is not sufficient
to restore the functionality, it has little effect.
No sleep at all makes almost no difference, ie,
such reload does not help.
The stalls looks like the server is suffering from
massive packet loss in receive path. It does not
lose all packets, and the amount of lost packets
increases with time, in a timeframe of several
minutes.
Doing a data transfer from a client machine to this
linux box, it goes at full ~10MB/s speed, next when
the stall is about to happen the speed drops to 6MB/s,
4, 1MB/s, 600KB/s, till eventually the connection just
times out.
The interesting data point is that the NIC does not
generate any interrupts during such stalls, as if
there's no packets are coming from the network at
all - even if during that time, the client workstations
are sending ARP requests (if nothing more).
Here's how ping on the server looks like (pinging one
of the machine on the LAN):
64 bytes from 192.168.78.20: icmp_seq=1 ttl=128 time=5008 ms
64 bytes from 192.168.78.20: icmp_seq=2 ttl=128 time=5000 ms
64 bytes from 192.168.78.20: icmp_seq=3 ttl=128 time=6000 ms
64 bytes from 192.168.78.20: icmp_seq=4 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=5 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=6 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=7 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=8 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=9 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=10 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=11 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=12 ttl=128 time=6320 ms
64 bytes from 192.168.78.20: icmp_seq=13 ttl=128 time=6000 ms
64 bytes from 192.168.78.20: icmp_seq=14 ttl=128 time=6000 ms
64 bytes from 192.168.78.20: icmp_seq=15 ttl=128 time=6000 ms
64 bytes from 192.168.78.20: icmp_seq=16 ttl=128 time=6000 ms
64 bytes from 192.168.78.20: icmp_seq=17 ttl=128 time=6000 ms
64 bytes from 192.168.78.20: icmp_seq=18 ttl=128 time=6000 ms
64 bytes from 192.168.78.20: icmp_seq=19 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=20 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=21 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=22 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=23 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=24 ttl=128 time=6007 ms
64 bytes from 192.168.78.20: icmp_seq=25 ttl=128 time=6001 ms
64 bytes from 192.168.78.20: icmp_seq=26 ttl=128 time=6010 ms
64 bytes from 192.168.78.20: icmp_seq=27 ttl=128 time=5014 ms
64 bytes from 192.168.78.20: icmp_seq=28 ttl=128 time=5011 ms
64 bytes from 192.168.78.20: icmp_seq=29 ttl=128 time=5020 ms
64 bytes from 192.168.78.20: icmp_seq=30 ttl=128 time=5020 ms
64 bytes from 192.168.78.20: icmp_seq=31 ttl=128 time=6018 ms
64 bytes from 192.168.78.20: icmp_seq=32 ttl=128 time=7010 ms
64 bytes from 192.168.78.20: icmp_seq=33 ttl=128 time=7008 ms
64 bytes from 192.168.78.20: icmp_seq=34 ttl=128 time=7000 ms
64 bytes from 192.168.78.20: icmp_seq=35 ttl=128 time=7000 ms
It looks like the NIC does not deliver any packets by its
own, but notices something arrived when you actually try
to _send_ sometihng - hence the delays above, almost whole
seconds (since ping sends data with 1sec intervals).
Here's normal ping output right after "restarting" the interface:
64 bytes from 192.168.78.20: icmp_seq=1 ttl=128 time=0.161 ms
64 bytes from 192.168.78.20: icmp_seq=2 ttl=128 time=0.119 ms
64 bytes from 192.168.78.20: icmp_seq=3 ttl=128 time=0.117 ms
64 bytes from 192.168.78.20: icmp_seq=4 ttl=128 time=0.381 ms
64 bytes from 192.168.78.20: icmp_seq=5 ttl=128 time=0.131 ms
64 bytes from 192.168.78.20: icmp_seq=6 ttl=128 time=0.133 ms
And at restart, the following gets printed in dmesg:
[ 3439.360831] forcedeth 0000:00:0a.0: irq 47 for MSI/MSI-X
So far we tried to replace everything in this network:
started with the NIC on the server, all wires, the switch,
and even replaced the client computers (upgraded them from
some old to current hardware). Even changing the NIC on
the server did not help - rtl8139 behaves the same way,
but it needs a bit more time to trigger the issue.
The problem happens with several different kernels - at
least 2.6.27 triggers it, 2.6.32 and 2.6.35 all behaves
the same, 32 or 64bit.
The machine is based on Asus M2N-VM DVI motherboard, which
is nVidia MCP67-based system. The NIC is on-board forcedeth
(and as I mentioned above the same prob happens with rtl8139
card).
This machine has 2 more NICs inserted (used for WAN link and
for another tiny LAN segment) - these does not show the issue,
but they both run at 10Mbps, so maybe it needs 10x more time.
When the eth0 LAN segment stops working, the rest of the system
works just fine, including these 2 NICs and hard drives.
I also tried to disable MSI, loading forcedeth with msi=0, -
this results in usage of IO-APIC-fasteoi for the NIC instead
of usual PCI-MSI-edge, but does not change the situation.
So I'm quite stuck here, and don't know what to do next.
My next bet is to try another motherboard, in a hope that
this is just some broken interrupt controller, but it is
a bit too unreal...
Any hints on what to try are greatly apprecated...
Thanks!
/mjt
^ permalink raw reply
* Re: PCI: make pci_restore_state return void
From: Michael Ellerman @ 2010-12-05 22:46 UTC (permalink / raw)
To: Jon Mason
Cc: Jesse Barnes, linux-pci-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-media-u79uwXL29TY76Z2rM5mHXA, Andrew Gallatin, Brice Goglin,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
Steve Hodgson, Ben Hutchings, Stephen Hemminger, Ivo van Doorn,
Gertjan van Wingerde, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
Brian King, Anil Ravindranath, linux-scsi-u79uwXL29TY76Z2rM5mHXA,
Jaya Kumar, boyod.yang-S9cbI//bT0v8C245oKUbwW/U75nxZMCp
In-Reply-To: <1291160606-31494-1-git-send-email-jon.mason-0FX2CSrisTk@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
On Tue, 2010-11-30 at 17:43 -0600, Jon Mason wrote:
> pci_restore_state only ever returns 0, thus there is no benefit in
> having it return any value. Also, a large majority of the callers do
> not check the return code of pci_restore_state. Make the
> pci_restore_state a void return and avoid the overhead.
It does kind of make me nervous that (basically) no one ever checks the
return code from the PCI config space accessors, even though in theory
they can fail. This code being but one example.
/end random comment :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] econet: Do the correct cleanup after an unprivileged SIOCSIFADDR.
From: Nelson Elhage @ 2010-12-05 22:45 UTC (permalink / raw)
To: David S. Miller, Phil Blundell; +Cc: netdev, Nelson Elhage, stable
We need to drop the mutex and do a dev_put, so set an error code and break like
the other paths, instead of returning directly.
Cc: stable@kernel.org
Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
---
net/econet/af_econet.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/econet/af_econet.c b/net/econet/af_econet.c
index 13992e1..f180371 100644
--- a/net/econet/af_econet.c
+++ b/net/econet/af_econet.c
@@ -661,8 +661,10 @@ static int ec_dev_ioctl(struct socket *sock, unsigned int cmd, void __user *arg)
err = 0;
switch (cmd) {
case SIOCSIFADDR:
- if (!capable(CAP_NET_ADMIN))
- return -EPERM;
+ if (!capable(CAP_NET_ADMIN)) {
+ err = -EPERM;
+ break;
+ }
edev = dev->ec_ptr;
if (edev == NULL) {
--
1.7.1.31.g6297e
^ permalink raw reply related
* IPsecv6 tunnel mode fragmentation
From: Joy Latten @ 2010-12-05 22:18 UTC (permalink / raw)
To: netdev; +Cc: samudrala, rashmin
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
We have come across an ipsec problem that I think was
noted a while back in the following link.
http://www.mail-archive.com/netdev@vger.kernel.org/msg61659.html
When an icmpv6 pkt-too-big message for a destination
is received, it is processed and the route's mtu is adjusted.
Transport mode uses "adjusted" mtu and works ok, but tunnel-mode
which has inner and outer iphdrs has problems.
ah and esp leave it to the ipv6 layer to fragment.
So, it seems esp/ah tunnel mode can produce an outgoing ipsec tunnel
mode pkt whose inner pkthdr has the dst with the adjusted mtu,
but inner pkt size larger than the adjusted mtu.
The outer pkthdr has tunnel's dst mtu which has not been
adjusted, since the pkt-too-big message was not for it.
So, ipv6 layer will use outer mtu to decide whether to fragment or not.
It doesn't appear to use the inner, "adjusted" mtu.
In the tcpdump attached below, since outer mtu is larger than the
outgoing pkt's size, it is not fragmented.
Thus lies the problem. So when the link with the "adjusted" mtu
gets the decrypted packet, the decrypted pkt may be too large for the
link's mtu. The "adjusted" mtu was never regarded when creating the pkt.
Hopefully, I have explained this clearly, if not
let me know. Should esp/ah pre-fragment... or should mtu of
inner pkt's dst be used for outer pkt? What's the best way to approach
this? Thanks for any info.
regards,
Joy
ipsec config:
target <-------> Secuity gateway <-----> host
(tunnel)
attachment is tcpdump from target.
[-- Attachment #2: target.bin --]
[-- Type: application/octet-stream, Size: 10236 bytes --]
^ permalink raw reply
* [PATCH] atm: correct sysfs 'device' link creation and parent relationships
From: Dan Williams @ 2010-12-05 22:17 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Duncan Sands, linux-usb-u79uwXL29TY76Z2rM5mHXA, Chas Williams,
Kay Sievers
The ATM subsystem was incorrectly creating the 'device' link for ATM
nodes in sysfs. This led to incorrect device/parent relationships
exposed by sysfs and udev. Instead of rolling the 'device' link by hand
in the generic ATM code, pass each ATM driver's bus device down to the
sysfs code and let sysfs do this stuff correctly.
Signed-off-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Note: I preserved original formatting for style consistency instead of
fixing up checkpatch.pl errors for "space required before XXXX".
diff --git a/drivers/atm/atmtcp.c b/drivers/atm/atmtcp.c
index b910181..2b464b6 100644
--- a/drivers/atm/atmtcp.c
+++ b/drivers/atm/atmtcp.c
@@ -366,7 +366,7 @@ static int atmtcp_create(int itf,int persist,struct atm_dev **result)
if (!dev_data)
return -ENOMEM;
- dev = atm_dev_register(DEV_LABEL,&atmtcp_v_dev_ops,itf,NULL);
+ dev = atm_dev_register(DEV_LABEL,NULL,&atmtcp_v_dev_ops,itf,NULL);
if (!dev) {
kfree(dev_data);
return itf == -1 ? -ENOMEM : -EBUSY;
diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index 97c5898..c495fae 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -2244,7 +2244,7 @@ static int __devinit eni_init_one(struct pci_dev *pci_dev,
&zeroes);
if (!cpu_zeroes) goto out1;
}
- dev = atm_dev_register(DEV_LABEL,&ops,-1,NULL);
+ dev = atm_dev_register(DEV_LABEL, &pci_dev->dev, &ops, -1, NULL);
if (!dev) goto out2;
pci_set_drvdata(pci_dev, dev);
eni_dev->pci_dev = pci_dev;
diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
index 5d86bb8..7d912ba 100644
--- a/drivers/atm/firestream.c
+++ b/drivers/atm/firestream.c
@@ -1911,7 +1911,7 @@ static int __devinit firestream_init_one (struct pci_dev *pci_dev,
fs_dev, sizeof (struct fs_dev));
if (!fs_dev)
goto err_out;
- atm_dev = atm_dev_register("fs", &ops, -1, NULL);
+ atm_dev = atm_dev_register("fs", &pci_dev->dev, &ops, -1, NULL);
if (!atm_dev)
goto err_out_free_fs_dev;
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 801e8b6..6cf59bf 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -366,7 +366,7 @@ he_init_one(struct pci_dev *pci_dev, const struct pci_device_id *pci_ent)
goto init_one_failure;
}
- atm_dev = atm_dev_register(DEV_LABEL, &he_ops, -1, NULL);
+ atm_dev = atm_dev_register(DEV_LABEL, &pci_dev->dev, &he_ops, -1, NULL);
if (!atm_dev) {
err = -ENODEV;
goto init_one_failure;
diff --git a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c
index 2f3516b..af37a5f 100644
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -771,7 +771,7 @@ static int __devinit ns_init_card(int i, struct pci_dev *pcidev)
}
/* Register device */
- card->atmdev = atm_dev_register("nicstar", &atm_ops, -1, NULL);
+ card->atmdev = atm_dev_register("nicstar", &card->pcidev->dev, &atm_ops, -1, NULL);
if (card->atmdev == NULL) {
printk("nicstar%d: can't register device.\n", i);
error = 17;
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 2e08c99..73fb1c4 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -166,7 +166,7 @@ static irqreturn_t solos_irq(int irq, void *dev_id);
static struct atm_vcc* find_vcc(struct atm_dev *dev, short vpi, int vci);
static int list_vccs(int vci);
static void release_vccs(struct atm_dev *dev);
-static int atm_init(struct solos_card *);
+static int atm_init(struct solos_card *, struct device *);
static void atm_remove(struct solos_card *);
static int send_command(struct solos_card *card, int dev, const char *buf, size_t size);
static void solos_bh(unsigned long);
@@ -1210,7 +1210,7 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
if (db_firmware_upgrade)
flash_upgrade(card, 3);
- err = atm_init(card);
+ err = atm_init(card, &dev->dev);
if (err)
goto out_free_irq;
@@ -1233,7 +1233,7 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
return err;
}
-static int atm_init(struct solos_card *card)
+static int atm_init(struct solos_card *card, struct device *parent)
{
int i;
@@ -1244,7 +1244,7 @@ static int atm_init(struct solos_card *card)
skb_queue_head_init(&card->tx_queue[i]);
skb_queue_head_init(&card->cli_queue[i]);
- card->atmdev[i] = atm_dev_register("solos-pci", &fpga_ops, -1, NULL);
+ card->atmdev[i] = atm_dev_register("solos-pci", parent, &fpga_ops, -1, NULL);
if (!card->atmdev[i]) {
dev_err(&card->dev->dev, "Could not register ATM device %d\n", i);
atm_remove(card);
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index 05bf5a2..989e16e 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -951,7 +951,9 @@ static int usbatm_atm_init(struct usbatm_data *instance)
* condition: callbacks we register can be executed at once, before we have
* initialized the struct atm_dev. To protect against this, all callbacks
* abort if atm_dev->dev_data is NULL. */
- atm_dev = atm_dev_register(instance->driver_name, &usbatm_atm_devops, -1, NULL);
+ atm_dev = atm_dev_register(instance->driver_name,
+ &instance->usb_intf->dev, &usbatm_atm_devops,
+ -1, NULL);
if (!atm_dev) {
usb_err(instance, "%s: failed to register ATM device!\n", __func__);
return -1;
@@ -966,14 +968,6 @@ static int usbatm_atm_init(struct usbatm_data *instance)
/* temp init ATM device, set to 128kbit */
atm_dev->link_rate = 128 * 1000 / 424;
- ret = sysfs_create_link(&atm_dev->class_dev.kobj,
- &instance->usb_intf->dev.kobj, "device");
- if (ret) {
- atm_err(instance, "%s: sysfs_create_link failed: %d\n",
- __func__, ret);
- goto fail_sysfs;
- }
-
if (instance->driver->atm_start && ((ret = instance->driver->atm_start(instance, atm_dev)) < 0)) {
atm_err(instance, "%s: atm_start failed: %d!\n", __func__, ret);
goto fail;
@@ -992,8 +986,6 @@ static int usbatm_atm_init(struct usbatm_data *instance)
return 0;
fail:
- sysfs_remove_link(&atm_dev->class_dev.kobj, "device");
- fail_sysfs:
instance->atm_dev = NULL;
atm_dev_deregister(atm_dev); /* usbatm_atm_dev_close will eventually be called */
return ret;
@@ -1329,7 +1321,6 @@ void usbatm_usb_disconnect(struct usb_interface *intf)
/* ATM finalize */
if (instance->atm_dev) {
- sysfs_remove_link(&instance->atm_dev->class_dev.kobj, "device");
atm_dev_deregister(instance->atm_dev);
instance->atm_dev = NULL;
}
diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
index a8e4e83..475f8c4 100644
--- a/include/linux/atmdev.h
+++ b/include/linux/atmdev.h
@@ -427,8 +427,10 @@ extern rwlock_t vcc_sklist_lock;
#define ATM_SKB(skb) (((struct atm_skb_data *) (skb)->cb))
-struct atm_dev *atm_dev_register(const char *type,const struct atmdev_ops *ops,
- int number,unsigned long *flags); /* number == -1: pick first available */
+struct atm_dev *atm_dev_register(const char *type, struct device *parent,
+ const struct atmdev_ops *ops,
+ int number, /* -1 == pick first available */
+ unsigned long *flags);
struct atm_dev *atm_dev_lookup(int number);
void atm_dev_deregister(struct atm_dev *dev);
diff --git a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c
index 799c631..f7fa67c 100644
--- a/net/atm/atm_sysfs.c
+++ b/net/atm/atm_sysfs.c
@@ -143,12 +143,13 @@ static struct class atm_class = {
.dev_uevent = atm_uevent,
};
-int atm_register_sysfs(struct atm_dev *adev)
+int atm_register_sysfs(struct atm_dev *adev, struct device *parent)
{
struct device *cdev = &adev->class_dev;
int i, j, err;
cdev->class = &atm_class;
+ cdev->parent = parent;
dev_set_drvdata(cdev, adev);
dev_set_name(cdev, "%s%d", adev->type, adev->number);
diff --git a/net/atm/resources.c b/net/atm/resources.c
index d29e582..23f45ce 100644
--- a/net/atm/resources.c
+++ b/net/atm/resources.c
@@ -74,8 +74,9 @@ struct atm_dev *atm_dev_lookup(int number)
}
EXPORT_SYMBOL(atm_dev_lookup);
-struct atm_dev *atm_dev_register(const char *type, const struct atmdev_ops *ops,
- int number, unsigned long *flags)
+struct atm_dev *atm_dev_register(const char *type, struct device *parent,
+ const struct atmdev_ops *ops, int number,
+ unsigned long *flags)
{
struct atm_dev *dev, *inuse;
@@ -115,7 +116,7 @@ struct atm_dev *atm_dev_register(const char *type, const struct atmdev_ops *ops,
goto out_fail;
}
- if (atm_register_sysfs(dev) < 0) {
+ if (atm_register_sysfs(dev, parent) < 0) {
pr_err("atm_register_sysfs failed for dev %s\n", type);
atm_proc_dev_deregister(dev);
goto out_fail;
diff --git a/net/atm/resources.h b/net/atm/resources.h
index 126fb18..521431e 100644
--- a/net/atm/resources.h
+++ b/net/atm/resources.h
@@ -42,6 +42,6 @@ static inline void atm_proc_dev_deregister(struct atm_dev *dev)
#endif /* CONFIG_PROC_FS */
-int atm_register_sysfs(struct atm_dev *adev);
+int atm_register_sysfs(struct atm_dev *adev, struct device *parent);
void atm_unregister_sysfs(struct atm_dev *adev);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: PATCH] filter: fix sk_filter rcu handling
From: Eric Dumazet @ 2010-12-05 21:28 UTC (permalink / raw)
To: Andi Kleen
Cc: netdev, hagen, stable, xiaosuo, wirelesser, Paul E. McKenney,
David Miller, Pavel Emelyanov
In-Reply-To: <20101205210840.GB7668@basil.fritz.box>
Le dimanche 05 décembre 2010 à 22:08 +0100, Andi Kleen a écrit :
> > While working on this, I found an annoying problem with current code.
> >
> > This patch is a stable candidate.
>
> Does this actually fix a real world problem someone is experiencing?
> "Theoretical races" are normally outside stable's scope.
>
> -Andi
I guess its a security problem.
We can probably write a program, run by unpriviledge user to crash the
machine.
I am not sure I want to spend time to write this program, I have other
more interesting topics, but some hackers probably want to.
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: PATCH] filter: fix sk_filter rcu handling
From: Andi Kleen @ 2010-12-05 21:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, hagen, stable, xiaosuo, wirelesser, Paul E. McKenney,
David Miller, Pavel Emelyanov
In-Reply-To: <1291582432.2806.300.camel@edumazet-laptop>
> While working on this, I found an annoying problem with current code.
>
> This patch is a stable candidate.
Does this actually fix a real world problem someone is experiencing?
"Theoretical races" are normally outside stable's scope.
-Andi
^ permalink raw reply
* Re: [PATCH] net: init ingress queue
From: Eric Dumazet @ 2010-12-05 21:05 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, Jiri Pirko, netdev
In-Reply-To: <1291465901-3189-1-git-send-email-xiaosuo@gmail.com>
Le samedi 04 décembre 2010 à 20:31 +0800, Changli Gao a écrit :
> The dev field of ingress queue is forgot to initialized, then NULL
> pointer dereference happens in qdisc_alloc().
>
> Move inits of tx queues to netif_alloc_netdev_queues().
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ---
> v2: factorize the two inits in netdev_init_queues() and move inits of
> tx queues to netif_alloc_netdev_queues().
This is a net-next-2.6 patch, you forgot to mention it.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* PATCH] filter: fix sk_filter rcu handling
From: Eric Dumazet @ 2010-12-05 20:53 UTC (permalink / raw)
To: David Miller
Cc: netdev, hagen, xiaosuo, wirelesser, Paul E. McKenney, stable,
Pavel Emelyanov
In-Reply-To: <1291357953.2854.46.camel@edumazet-laptop>
Le vendredi 03 décembre 2010 à 07:32 +0100, Eric Dumazet a écrit :
> Le mercredi 01 décembre 2010 à 10:18 -0800, David Miller a écrit :
>
> > However, I think it's still valuable to write a few JIT compilers for
> > the existing BPF stuff. I considered working on a sparc64 JIT just to
> > see what it would look like.
> >
> > If people work on the BPF optimizer and BPF JITs in parallel, we'll have
> > both ready at the same time. win++
>
> I began work on implementing a BPF JIT for x86_64
>
> My plan is to use external helpers to load skb data/metadata, to keep
> BPF program very short and have no dependencies against struct layouts.
>
> These helpers would be the three load_word, load_half, load_byte.
>
> In case the bits are in skb head, these helpers should be fast.
>
> For practical reasons, they would be in ASM for their fast path, and C
> for the slow path. They are ASM because they are able to perform the
> shortcut (in case of error, doing the stack unwind to perform the
> "return 0;") so that we dont have to test their return from the JIT
> program.
>
>
While working on this, I found an annoying problem with current code.
This patch is a stable candidate.
Thanks
[PATCH] filter: fix sk_filter rcu handling
Pavel Emelyanov tried to fix a race between sk_filter_(de|at)tach and
sk_clone() in commit 47e958eac280c263397
Problem is we can have several clones sharing a common sk_filter, and
these clones might want to sk_filter_attach() their own filters at the
same time, and can overwrite old_filter->rcu, corrupting RCU queues.
We can not use filter->rcu without being sure no other thread could do
the same thing.
Switch code to a more conventional ref-counting technique : Do the
atomic decrement immediately and queue one rcu call back when last
reference is released.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: stable@kernel.org
---
include/net/sock.h | 4 +++-
net/core/filter.c | 19 ++++++-------------
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index a6338d0..4308af7 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1155,6 +1155,8 @@ extern void sk_common_release(struct sock *sk);
/* Initialise core socket variables */
extern void sock_init_data(struct socket *sock, struct sock *sk);
+extern void sk_filter_release_rcu(struct rcu_head *rcu);
+
/**
* sk_filter_release - release a socket filter
* @fp: filter to remove
@@ -1165,7 +1167,7 @@ extern void sock_init_data(struct socket *sock, struct sock *sk);
static inline void sk_filter_release(struct sk_filter *fp)
{
if (atomic_dec_and_test(&fp->refcnt))
- kfree(fp);
+ call_rcu_bh(&fp->rcu, sk_filter_release_rcu);
}
static inline void sk_filter_uncharge(struct sock *sk, struct sk_filter *fp)
diff --git a/net/core/filter.c b/net/core/filter.c
index c1ee800..ae21a0d 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -589,23 +589,16 @@ int sk_chk_filter(struct sock_filter *filter, int flen)
EXPORT_SYMBOL(sk_chk_filter);
/**
- * sk_filter_rcu_release - Release a socket filter by rcu_head
+ * sk_filter_release_rcu - Release a socket filter by rcu_head
* @rcu: rcu_head that contains the sk_filter to free
*/
-static void sk_filter_rcu_release(struct rcu_head *rcu)
+void sk_filter_release_rcu(struct rcu_head *rcu)
{
struct sk_filter *fp = container_of(rcu, struct sk_filter, rcu);
- sk_filter_release(fp);
-}
-
-static void sk_filter_delayed_uncharge(struct sock *sk, struct sk_filter *fp)
-{
- unsigned int size = sk_filter_len(fp);
-
- atomic_sub(size, &sk->sk_omem_alloc);
- call_rcu_bh(&fp->rcu, sk_filter_rcu_release);
+ kfree(fp);
}
+EXPORT_SYMBOL(sk_filter_release_rcu);
/**
* sk_attach_filter - attach a socket filter
@@ -649,7 +642,7 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
rcu_assign_pointer(sk->sk_filter, fp);
if (old_fp)
- sk_filter_delayed_uncharge(sk, old_fp);
+ sk_filter_uncharge(sk, old_fp);
return 0;
}
EXPORT_SYMBOL_GPL(sk_attach_filter);
@@ -663,7 +656,7 @@ int sk_detach_filter(struct sock *sk)
sock_owned_by_user(sk));
if (filter) {
rcu_assign_pointer(sk->sk_filter, NULL);
- sk_filter_delayed_uncharge(sk, filter);
+ sk_filter_uncharge(sk, filter);
ret = 0;
}
return ret;
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply related
* 2.6.37-rc4-git4: Reported regressions 2.6.35 -> 2.6.36
From: Rafael J. Wysocki @ 2010-12-05 20:15 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
This message contains a list of some post-2.6.35 regressions introduced before
2.6.36, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.35 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-05 95 34 31
2010-11-19 92 38 34
2010-10-17 70 27 27
2010-10-10 56 16 15
2010-10-03 52 16 14
2010-09-26 46 15 13
2010-09-20 38 15 15
2010-09-12 28 14 13
2010-08-30 21 16 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24022
Subject : wireless no longer works after 1st update of 10.10 [rtl819xE:ERR in init_firmware()]
Submitter : njin <marconifabio@ubuntu-it.org>
Date : 2010-11-29 19:49 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23812
Subject : HAL does not provide battery information on RHEL5 and CentOS-5
Submitter : Dag Wieers <dag@wieers.com>
Date : 2010-11-26 18:08 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23302
Subject : alsa stops working after one or more hibernate or suspend cycles
Submitter : Werner Lemberg <wl@gnu.org>
Date : 2010-11-19 16:21 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23132
Subject : without "pci=nocrs", Dell Inspiron 1545 hangs
Submitter : Bjorn Helgaas <bjorn.helgaas@hp.com>
Date : 2010-11-17 19:18 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22842
Subject : iwl3945 suddenly stops working
Submitter : Felipe Contreras <felipe.contreras@gmail.com>
Date : 2010-11-14 11:14 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22782
Subject : 2.6.36: general protection fault during lockfs lockspace removal
Submitter : nik@linuxbox.cz <nik@linuxbox.cz>
Date : 2010-11-12 12:05 (24 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22732
Subject : 2.6.37-rc1: hibernation breaks swap
Submitter : Zhang Rui <rui.zhang@intel.com>
Date : 2010-11-11 08:38 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22272
Subject : High [extra timer interrupt] count in powertop since 2.6.36
Submitter : Ian Kumlien <pomac@demius.net>
Date : 2010-10-30 23:52 (37 days old)
Message-ID : <alpine.LNX.2.00.1010310148450.24290@twilight.pomac.com>
References : http://marc.info/?l=linux-kernel&m=128848330304431&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22172
Subject : alsa-util.c: snd_pcm_avail_delay() returned strange values: delay 0 is less than avail 32
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-06 09:33 (30 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22092
Subject : Kernel v2.6.36 trouble on USB disconnect
Submitter : Ketil Froyn <ketil@froyn.name>
Date : 2010-10-29 8:05 (38 days old)
Message-ID : <AANLkTik5qVxkEGVAA1PSOGk2KTW+ekHpSwttsQEWzWj+@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128833956503607&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21662
Subject : 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
Submitter : Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Date : 2010-10-25 9:22 (42 days old)
Message-ID : <201010251222.37191.nuclearcat@nuclearcat.com>
References : http://marc.info/?l=linux-kernel&m=128799855826011&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21652
Subject : several problems with intel graphics since 2.6.36
Submitter : Norbert Preining <preining@logic.at>
Date : 2010-10-27 14:32 (40 days old)
Message-ID : <20101027143252.GA8676@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=128818998630241&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21402
Subject : [KVM] Noacpi Windows guest can not boot up on 32bit KVM host
Submitter : xudong <xudong.hao@intel.com>
Date : 2010-10-29 03:01 (38 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21372
Subject : NULL pointer deference at disk_replace_part_tbl+0x32
Submitter : Luis R. Rodriguez <mcgrof@gmail.com>
Date : 2010-10-28 17:22 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20352
Subject : Fwd: Re: UML kernel crash of v2.6.36-rcX kernel
Submitter : Toralf Förster <toralf.foerster@gmx.de>
Date : 2010-10-13 11:28 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/365b18189789bfa1acd9939e6312b8a4b4577b28
Message-ID : <201010131328.06465.toralf.foerster@gmx.de>
References : http://marc.info/?l=linux-kernel&m=128696930132503&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20342
Subject : [LogFS] [2.6.36-rc7] Deadlock in logfs_get_wblocks, hold and wait on same lock super->s_write_mutex
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-13 9:49 (54 days old)
Message-ID : <AANLkTinvsMxTxEbDEFmb5M-6fYjdRvErU==Zs7+qANkV@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128696335024718&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20332
Subject : [LogFS] [2.6.36-rc7] Kernel BUG at lib/btree.c:465!
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-12 18:56 (55 days old)
Message-ID : <AANLkTimAbCZNhLQ5nADUiAC+7JpAeJBEmjFwdxyZ-FxO@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128690910501830&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20322
Subject : 2.6.36-rc7: inconsistent lock state: inconsistent {IN-RECLAIM_FS-R} -> {RECLAIM_FS-ON-W} usage.
Submitter : Dave Jones <davej@redhat.com>
Date : 2010-10-11 20:10 (56 days old)
Message-ID : <20101011201007.GA29707@redhat.com>
References : http://marc.info/?l=linux-kernel&m=128682782828453&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20232
Subject : kworker consumes ~100% CPU on HP Elitebook 8540w running 2.6.36_rc6-git4
Submitter : Ozan Caglayan <ozan@pardus.org.tr>
Date : 2010-10-13 06:13 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19802
Subject : [drm:init_ring_common] *ERROR* render ring head not reset to zero
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2010-10-04 20:31 (63 days old)
Message-ID : <201010042231.20320.thomas@m3y3r.de>
References : http://marc.info/?l=linux-kernel&m=128622441331199&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19782
Subject : 2.6.36-rc6-git2 -- BUG dentry: Poison overwritten (after resume from hibernation)
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-10-03 3:54 (64 days old)
Message-ID : <AANLkTimrqtzBHAZSuDhEs_3CKA6pCbM35b1BtKH=MvC_@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128607809314079&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19632
Subject : 2.6.36-rc6: modprobe Not tainted warning
Submitter : Heinz Diehl <htd@fritha.org>
Date : 2010-09-30 18:25 (67 days old)
Message-ID : <20100930182516.GA15089@fritha.org>
References : http://marc.info/?l=linux-kernel&m=128587114004680&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19392
Subject : WARNING: at drivers/net/wireless/ath/ath5k/base.c:3475 ath5k_bss_info_changed+0x44/0x168 [ath5k]()
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2010-09-28 22:30 (69 days old)
Message-ID : <<AANLkTim5WCGKPvEkOkO_YnMF9pg8mvLfQoFBNUFpfa_k@mail.gmail.com>>
References : http://marc.info/?l=linux-kernel&m=128571307018635&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19372
Subject : 2.6.36-rc6: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x35a/0x3c0
Submitter : Alexey Dobriyan <adobriyan@gmail.com>
Date : 2010-09-29 21:29 (68 days old)
Message-ID : <20100929212923.GA5578@core2.telecom.by>
References : http://marc.info/?l=linux-kernel&m=128579579400315&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19142
Subject : Screen flickers when switching from the console to X
Submitter : Andrey Rahmatullin <wrar@wrar.name>
Date : 2010-09-27 12:05 (70 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19052
Subject : 2.6.36-rc5-git1 -- [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-09-22 23:47 (75 days old)
Message-ID : <AANLkTikWQjUQjFJU9MO1+XbSLAEE-GARz+S+Dz2Fgu4h@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128519926626322&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19002
Subject : Radeon rv730 AGP/KMS/DRM kernel lockup
Submitter : Duncan <1i5t5.duncan@cox.net>
Date : 2010-09-23 16:48 (74 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17121
Subject : Two blank rectangles more than 10 cm long when booting
Submitter : Eric Valette <eric.valette@free.fr>
Date : 2010-08-26 17:24 (102 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject : 2.6.36-rc1 on zaurus: bluetooth regression
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-08-21 15:24 (107 days old)
Message-ID : <20100821152445.GA1536@ucw.cz>
References : http://marc.info/?l=linux-kernel&m=128240433828087&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject : qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2010-08-19 21:03 (109 days old)
Message-ID : <<<alpine.SOC.1.00.1008192359310.19654@math.ut.ee>>>
References : http://marc.info/?l=linux-kernel&m=128225184900892&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject : hackbench regression with 2.6.36-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-08-18 6:18 (110 days old)
Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=128211235904910&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21092
Subject : Kernel 2.6.36 Bug during quotaon on reiserfs
Submitter : <markus.gapp@gmx.net>
Date : 2010-10-24 16:57 (43 days old)
Handled-By : Jan Kara <jack@suse.cz>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=35292
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20462
Subject : 2.6.36-rc7-git2 - panic/GPF: e1000e/vlans?
Submitter : Nikola Ciprich <extmaillist@linuxbox.cz>
Date : 2010-10-15 7:10 (52 days old)
Message-ID : <20101015071008.GA8714@pcnci.linuxbox.cz>
References : http://marc.info/?l=linux-kernel&m=128712984831303&w=2
Handled-By : Jesse Gross <jesse@nicira.com>
Patch : http://www.spinics.net/lists/netdev/msg146227.html
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20162
Subject : [LogFS][2.6.36.rc7+] Kernel BUG at readwrite.c:1193
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-10 17:44 (57 days old)
Message-ID : <AANLkTi=JkcuWBPo+X-i+9o-BJFVqjea1J3e=Mr=HvAWF@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128673196203340&w=2
Handled-By : Prasad Gajanan Joshi <prasadjoshi124@gmail.com>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=20162#c1
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.35 and 2.6.36, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16444
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: [PATCH 3/3] ifb: move tq from ifb_private
From: Jarek Poplawski @ 2010-12-05 19:09 UTC (permalink / raw)
To: jamal; +Cc: Changli Gao, netdev
In-Reply-To: <1291559231.2159.684.camel@mojatatu>
On Sun, Dec 05, 2010 at 09:27:11AM -0500, jamal wrote:
...
> PS:- We forgot to thank Jarek for pointing out the bug.
Not at all! I only pointed out that Changli didn't point out ;-)
All credits go to him and you for pointing out the appropriate fix.
Cheers,
Jarek P.
^ permalink raw reply
* Re: Question about __alloc_skb() speedup
From: Eric Dumazet @ 2010-12-05 16:49 UTC (permalink / raw)
To: Junchang Wang; +Cc: netdev
In-Reply-To: <20101205105616.GA4770@Desktop-Junchang>
Le dimanche 05 décembre 2010 à 18:56 +0800, Junchang Wang a écrit :
> On Sat, Dec 04, 2010 at 03:47:38PM +0100, Eric Dumazet wrote:
> >
> >Yes I believe so, pktgen being very specific, but I have few questions :
> >
> >Is it with SLUB or SLAB ?
> I had read your discussion about "net: allocate skbs on local node" in
> the list, so SLUB was used.
>
> BTW, what I observed is that network subsystem scales well on NUMA
> systems equipped with a single processor(up to six cores), but the
> performance didn't scale very well if there are two processors.
>
> I have noticed there are a number of discussions in the list. Are
> there any suggestions? I'm very pleasant to do test.
>
> >
> >How many buffers in TX ring on you nic (ethtool -g eth0) ?
> >
> Pre-set maximums:
> RX: 4096
> RX Mini: 0
> RX Jumbo: 0
> TX: 4096
> Current hardware settings:
> RX: 512
> RX Mini: 0
> RX Jumbo: 0
> TX: 512
>
> >What is the datalen value here ? (you prefetch, then advance skb->data)
> >
> 16. But the following skb_push will drawback 14 bytes.
>
> >32 or 64bit kernel ?
> >
> This is a CentOS 5.5 - 64bit distribution with the latest net-next.
>
> >How many pps do you get before and after patch ?
> >
> A Intel SR1625 server with two E5530 quad-core processors and a single
> ixgbe-based NIC.
> Without prefetch: 8.63 Mpps
> With prefetch: 9.03 Mpps
> Improvement: 4.6%
>
>
Thanks Junchang, please submit your pktgen patch with the two added
prefetchw(), I'll Ack it :)
^ permalink raw reply
* Re: [PATCH 3/3] ifb: move tq from ifb_private
From: jamal @ 2010-12-05 15:31 UTC (permalink / raw)
To: Changli Gao; +Cc: Jarek Poplawski, netdev
In-Reply-To: <AANLkTimLd=d94Cnh8dsX8HFFeYM4mBGH1gpK+p3YT-hm@mail.gmail.com>
On Sun, 2010-12-05 at 23:22 +0800, Changli Gao wrote:
> The current implementation can guarantee it. However, I can't find
> documentation about this 'feature', but I think this behavior should
> not be changed in future since maybe some call sites relay on it.
When you think you are in good shape - please add some debug hooks
so we can verify this especially under a huge traffic input and
I will test it (thats what end of year holidays are for).
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 3/3] ifb: move tq from ifb_private
From: Changli Gao @ 2010-12-05 15:22 UTC (permalink / raw)
To: hadi; +Cc: Jarek Poplawski, netdev
In-Reply-To: <1291562028.2159.692.camel@mojatatu>
On Sun, Dec 5, 2010 at 11:13 PM, jamal <hadi@cyberus.ca> wrote:
> On Sun, 2010-12-05 at 22:40 +0800, Changli Gao wrote:
>> On Sun, Dec 5, 2010 at 10:30 PM, jamal <hadi@cyberus.ca> wrote:
>
>> > - we use tasklets. When we reschedule we can end up on a differrent
>> > cpu.
>>
>> The tasklets always been scheduled to the current CPU unless it has
>> been schedule already on the other CPU.
>
> I dont think this can be guaranteed - So the potential of packet
> reordering exists.
>
The current implementation can guarantee it. However, I can't find
documentation about this 'feature', but I think this behavior should
not be changed in future since maybe some call sites relay on it.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 3/3] ifb: move tq from ifb_private
From: Changli Gao @ 2010-12-05 15:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: hadi, Jarek Poplawski, netdev
In-Reply-To: <1291562016.2806.257.camel@edumazet-laptop>
On Sun, Dec 5, 2010 at 11:13 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le dimanche 05 décembre 2010 à 22:40 +0800, Changli Gao a écrit :
>> On Sun, Dec 5, 2010 at 10:30 PM, jamal <hadi@cyberus.ca> wrote:
>> > On Sun, 2010-12-05 at 09:13 +0800, Changli Gao wrote:
>> >
>> >> BTW: My ultimate goal is making ifb a multi-queue NIC, and the number
>> >> of queues is equal to the number of the possible CPUs.
>> >
>> >
>> > My view is this is going to be tricky because:
>> > - we use tasklets. When we reschedule we can end up on a differrent
>> > cpu.
>>
>> The tasklets always been scheduled to the current CPU unless it has
>> been schedule already on the other CPU.
>>
>> > -I dont see any point in having a separate softIRQ
>> > - and if you do use other mechanisms it would require a lot more
>> > testing since there are quiet a few use cases of ifb
>> >
>>
>> I keep using tasklet. The attachment is the alpha version.
>>
>
> for_each_possible_cpu(cpu) {
> q = per_cpu_ptr(p->q, cpu);
> ...
>
> dev_ifb = alloc_netdev_mq(sizeof(struct ifb_private), "ifb%d",
> ifb_setup, num_possible_cpus());
>
> This is a very usual error.
>
> You can have machines with 2 possibles cpus, numbered 0 and 8
>
> Therere, you must use nr_cpu_ids here instead of num_possible_cpus()
>
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 3/3] ifb: move tq from ifb_private
From: jamal @ 2010-12-05 15:13 UTC (permalink / raw)
To: Changli Gao; +Cc: Jarek Poplawski, netdev
In-Reply-To: <AANLkTimXDTTNcrFPngzEuoDGVgojtBxUZQPOMiSA7yNw@mail.gmail.com>
On Sun, 2010-12-05 at 22:40 +0800, Changli Gao wrote:
> On Sun, Dec 5, 2010 at 10:30 PM, jamal <hadi@cyberus.ca> wrote:
> > - we use tasklets. When we reschedule we can end up on a differrent
> > cpu.
>
> The tasklets always been scheduled to the current CPU unless it has
> been schedule already on the other CPU.
I dont think this can be guaranteed - So the potential of packet
reordering exists.
> I keep using tasklet. The attachment is the alpha version.
>From quick glance I dont see any technicalities - just the
reordering concern.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 3/3] ifb: move tq from ifb_private
From: Eric Dumazet @ 2010-12-05 15:13 UTC (permalink / raw)
To: Changli Gao; +Cc: hadi, Jarek Poplawski, netdev
In-Reply-To: <AANLkTimXDTTNcrFPngzEuoDGVgojtBxUZQPOMiSA7yNw@mail.gmail.com>
Le dimanche 05 décembre 2010 à 22:40 +0800, Changli Gao a écrit :
> On Sun, Dec 5, 2010 at 10:30 PM, jamal <hadi@cyberus.ca> wrote:
> > On Sun, 2010-12-05 at 09:13 +0800, Changli Gao wrote:
> >
> >> BTW: My ultimate goal is making ifb a multi-queue NIC, and the number
> >> of queues is equal to the number of the possible CPUs.
> >
> >
> > My view is this is going to be tricky because:
> > - we use tasklets. When we reschedule we can end up on a differrent
> > cpu.
>
> The tasklets always been scheduled to the current CPU unless it has
> been schedule already on the other CPU.
>
> > -I dont see any point in having a separate softIRQ
> > - and if you do use other mechanisms it would require a lot more
> > testing since there are quiet a few use cases of ifb
> >
>
> I keep using tasklet. The attachment is the alpha version.
>
for_each_possible_cpu(cpu) {
q = per_cpu_ptr(p->q, cpu);
...
dev_ifb = alloc_netdev_mq(sizeof(struct ifb_private), "ifb%d",
ifb_setup, num_possible_cpus());
This is a very usual error.
You can have machines with 2 possibles cpus, numbered 0 and 8
Therere, you must use nr_cpu_ids here instead of num_possible_cpus()
^ 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