* Re: [PATCH] aoe: remove dev_base_lock use from aoecmd_cfg_pkts()
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ecashin
In-Reply-To: <1288350929.2560.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 29 Oct 2010 13:15:29 +0200
> dev_base_lock is the legacy way to lock the device list, and is planned
> to disappear. (writers hold RTNL, readers hold RCU lock)
>
> Convert aoecmd_cfg_pkts() to RCU locking.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ks8851: suspend resume support
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: x0066660; +Cc: netdev
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A530468882D59@dlee03.ent.ti.com>
From: "Arce, Abraham" <x0066660@ti.com>
Date: Thu, 28 Oct 2010 23:57:20 -0500
> Add suspend/resume support using default open/stop interface methods
> to do hardware dependant operations.
>
> On suspend, same low power state (soft power mode) will be kept, the
> following blocks will be disabled:
>
> - Internal PLL Clock
> - Tx/Rx PHY
> - MAC
> - SPI Interface
>
> Signed-off-by: Abraham Arce <x0066660@ti.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 2/2] qlge: Version change to v1.00.00.27
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <1288191507-1994-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Wed, 27 Oct 2010 07:58:27 -0700
> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/2] qlge: Add firmware info to ethtool get regs.
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <1288191507-1994-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Wed, 27 Oct 2010 07:58:26 -0700
> By default we add firmware information to ethtool get regs.
> Optionally firmware info can instead be sent to log.
>
> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied.
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-08 21:40 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4CD86B4D.6020406@candelatech.com>
Le lundi 08 novembre 2010 à 13:27 -0800, Ben Greear a écrit :
> On 11/08/2010 03:02 AM, Eric Dumazet wrote:
> > Le samedi 06 novembre 2010 à 10:08 -0700, Ben Greear a écrit :
> >
> >> At least I don't see any percpu dumps in dmesg. I vaguely remember
> >> someone posting some ipv6 address scalability patches some time back.
> >> I think they had to hack on /proc fs as well. I'll see if I can
> >> dig those up.
> >>
> >>> Make sure udev / hotplug is not the problem, if you create your devices
> >>> very fast.
> >>
> >> We can create the macvlans w/out problem, though I'm sure that could
> >> be sped up. The problem is when we try to add IPv6 addresses to
> >> them.
> >
> > I see. Did you check /proc/sys/net/ipv6/ tunables ?
> >
> > For example, I bet you need to make route/max_size a bigger value than
> > default (4096)
>
> I'm having a hard time figuring out how this actually causes something
> to fail.
>
> It seems that having max_size too small would cause the garbage collector
> logic to happen more often, but I don't see any place it actually
> removes or limits entries, and I can't find any other references to
> ip6_rt_max_size.
>
> I must just be missing something..so if you have any ideas where to
> look, I'd love to hear it!
>
ipv6_add_addr() calls addrconf_dst_alloc
addrconf_dst_alloc() calls dst_alloc
dst_alloc() calls ip6_dst_gc
ip6_dst_gc() calls fib6_run_gc
fib6_run_gc() calls icmp6_dst_gc
fib6_run_gc() calls fib6_clean_all
a bit later, we return to ipv6_add_addr() (line 644) with an error
You want to add a warning in net/ipv6/route.c, line 1949
Thanks
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-08 21:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev
In-Reply-To: <1289214131.2820.187.camel@edumazet-laptop>
On 11/08/2010 03:02 AM, Eric Dumazet wrote:
> Le samedi 06 novembre 2010 à 10:08 -0700, Ben Greear a écrit :
>
>> At least I don't see any percpu dumps in dmesg. I vaguely remember
>> someone posting some ipv6 address scalability patches some time back.
>> I think they had to hack on /proc fs as well. I'll see if I can
>> dig those up.
>>
>>> Make sure udev / hotplug is not the problem, if you create your devices
>>> very fast.
>>
>> We can create the macvlans w/out problem, though I'm sure that could
>> be sped up. The problem is when we try to add IPv6 addresses to
>> them.
>
> I see. Did you check /proc/sys/net/ipv6/ tunables ?
>
> For example, I bet you need to make route/max_size a bigger value than
> default (4096)
I'm having a hard time figuring out how this actually causes something
to fail.
It seems that having max_size too small would cause the garbage collector
logic to happen more often, but I don't see any place it actually
removes or limits entries, and I can't find any other references to
ip6_rt_max_size.
I must just be missing something..so if you have any ideas where to
look, I'd love to hear it!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: David Miller @ 2010-11-08 21:26 UTC (permalink / raw)
To: jesse; +Cc: stable, netdev
In-Reply-To: <1289251381-6671-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Mon, 8 Nov 2010 13:23:01 -0800
> Normally hardware accelerated vlan packets are quickly dropped if
> there is no corresponding vlan device configured. The one exception
> is promiscuous mode, where we allow all of these packets through so
> they can be picked up by tcpdump. However, this behavior causes a
> crash if we actually try to receive these packets. This fixes that
> crash by ignoring packets with vids not corresponding to a configured
> device in the vlan hwaccel routines and then dropping them before they
> get to consumers in the network stack.
>
> This patch applies only to 2.6.36 stable. The problem was introduced
> in that release and is already fixed by larger changes to the vlan
> code in 2.6.37.
>
> Reported-by: Ben Greear <greearb@candelatech.com>
> Tested-by: Nikola Ciprich <extmaillist@linuxbox.cz>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: 2.6.36 vlans & bridge crash - status?
From: Jesse Gross @ 2010-11-08 21:25 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: netdev list, nikola.ciprich
In-Reply-To: <20101106071115.GA3264@nik-comp.lan>
On Sat, Nov 6, 2010 at 12:11 AM, Nikola Ciprich <extmaillist@linuxbox.cz> wrote:
> Hello Jesse,
> It really fixes the problem, thanks!
> Was the patch submitted to Greg for 2.6.36.y ?
Thanks for testing. I've submitted it to stable now.
^ permalink raw reply
* [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: Jesse Gross @ 2010-11-08 21:23 UTC (permalink / raw)
To: stable; +Cc: netdev, David Miller
Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured. The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump. However, this behavior causes a
crash if we actually try to receive these packets. This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.
This patch applies only to 2.6.36 stable. The problem was introduced
in that release and is already fixed by larger changes to the vlan
code in 2.6.37.
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Nikola Ciprich <extmaillist@linuxbox.cz>
Signed-off-by: Jesse Gross <jesse@nicira.com>
---
net/8021q/vlan_core.c | 3 +++
net/core/dev.c | 13 +++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 0eb96f7..2dcff0b 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -43,6 +43,9 @@ int vlan_hwaccel_do_receive(struct sk_buff *skb)
struct net_device *dev = skb->dev;
struct vlan_rx_stats *rx_stats;
+ if (unlikely(!is_vlan_dev(dev)))
+ return 0;
+
skb->dev = vlan_dev_info(dev)->real_dev;
netif_nit_deliver(skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 660dd41..dd72996 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2891,6 +2891,19 @@ static int __netif_receive_skb(struct sk_buff *skb)
ncls:
#endif
+ /* If we got this far with a hardware accelerated VLAN tag, it means
+ * that we were put in promiscuous mode but nobody is interested in
+ * this vid. Drop the packet now to prevent it from getting propagated
+ * to other parts of the stack that won't know how to deal with packets
+ * tagged in this manner.
+ */
+ if (unlikely(vlan_tx_tag_present(skb))) {
+ if (pt_prev)
+ ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ kfree_skb(skb);
+ goto out;
+ }
+
/* Handle special case of bridge or macvlan */
rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
--
1.7.1
^ permalink raw reply related
* Re: [RFC v2] ipvs: allow transmit of GRO aggregated skbs
From: Simon Horman @ 2010-11-08 21:22 UTC (permalink / raw)
To: Herbert Xu; +Cc: Julian Anastasov, lvs-devel, netdev
In-Reply-To: <20101108141955.GA31649@gondor.apana.org.au>
On Mon, Nov 08, 2010 at 10:19:55PM +0800, Herbert Xu wrote:
> On Mon, Nov 08, 2010 at 08:45:42PM +0900, Simon Horman wrote:
> >
> > > Yes, I think we should check for !skb_is_gso(skb)
> > > as it looks as correct check to avoid FRAG_NEEDED after GRO
> > > but lets wait for confirmation from Herbert Xu.
> >
> > Yes, lets try and get a word from Herbert Xu on this.
>
> Yes skb_is_gso(skb) is the best for now. It isn't 100% correct
> as we should still be checking that the gso_size is less than
> the MTU but we need to fix that elsewhere first.
Thanks Herbert.
^ permalink raw reply
* Re: [PATCH 2/2] IPv6: Warn users when route/max_entries is reached.
From: David Miller @ 2010-11-08 21:22 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <4CD86709.5090906@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Mon, 08 Nov 2010 13:09:29 -0800
> On 11/08/2010 11:13 AM, Ben Greear wrote:
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
...
> Please don't apply this. I mis-read this code and that warning
> is useless at best in this place.
Ok.
^ permalink raw reply
* [PATCH] inet: fix ip_mc_drop_socket()
From: Eric Dumazet @ 2010-11-08 21:15 UTC (permalink / raw)
To: Markus Trippelsdorf, David Miller
Cc: paulmck, Miles Lane, ilpo.jarvinen, LKML, Len Brown, netdev
In-Reply-To: <20101108205511.GB1585@arch.trippelsdorf.de>
Hmm, I believe I found the bug.
Thanks guys !
[PATCH] inet: fix ip_mc_drop_socket()
commit 8723e1b4ad9be4444 (inet: RCU changes in inetdev_by_index())
forgot one call site in ip_mc_drop_socket()
We should not decrease idev refcount after inetdev_by_index() call,
since refcount is not increased anymore.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Miles Lane <miles.lane@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/igmp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index c8877c6..3c53c2d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -2306,10 +2306,8 @@ void ip_mc_drop_socket(struct sock *sk)
in_dev = inetdev_by_index(net, iml->multi.imr_ifindex);
(void) ip_mc_leave_src(sk, iml, in_dev);
- if (in_dev != NULL) {
+ if (in_dev != NULL)
ip_mc_dec_group(in_dev, iml->multi.imr_multiaddr.s_addr);
- in_dev_put(in_dev);
- }
/* decrease mem now to avoid the memleak warning */
atomic_sub(sizeof(*iml), &sk->sk_omem_alloc);
call_rcu(&iml->rcu, ip_mc_socklist_reclaim);
^ permalink raw reply related
* Re: [PATCH 2/2] IPv6: Warn users when route/max_entries is reached.
From: Ben Greear @ 2010-11-08 21:09 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <1289243629-20789-2-git-send-email-greearb@candelatech.com>
On 11/08/2010 11:13 AM, Ben Greear wrote:
> Signed-off-by: Ben Greear<greearb@candelatech.com>
> ---
> :100644 100644 a275c6e... 348b34c... M net/ipv6/route.c
> net/ipv6/route.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index a275c6e..348b34c 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1060,8 +1060,12 @@ static int ip6_dst_gc(struct dst_ops *ops)
> unsigned long rt_last_gc = net->ipv6.ip6_rt_last_gc;
>
> if (time_after(rt_last_gc + rt_min_interval, now)&&
> - atomic_read(&ops->entries)<= rt_max_size)
> + atomic_read(&ops->entries)<= rt_max_size) {
> + if (net_ratelimit())
> + pr_warning("IPv6: Maximum number of routes reached,"
> + " consider increasing route/max_size.\n");
> goto out;
> + }
>
> net->ipv6.ip6_rt_gc_expire++;
> fib6_run_gc(net->ipv6.ip6_rt_gc_expire, net);
Please don't apply this. I mis-read this code and that warning
is useless at best in this place.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: 2.6.37-rc1-git5 -- WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
From: Markus Trippelsdorf @ 2010-11-08 20:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: paulmck, Miles Lane, ilpo.jarvinen, LKML, Len Brown, netdev
In-Reply-To: <1289249191.2790.3.camel@edumazet-laptop>
On Mon, Nov 08, 2010 at 09:46:31PM +0100, Eric Dumazet wrote:
> Le lundi 08 novembre 2010 à 21:42 +0100, Markus Trippelsdorf a écrit :
> > On Mon, Nov 08, 2010 at 09:29:26PM +0100, Eric Dumazet wrote:
> > > Le lundi 08 novembre 2010 à 12:06 -0800, Paul E. McKenney a écrit :
> > > > On Mon, Nov 08, 2010 at 02:56:06PM -0500, Miles Lane wrote:
> > > > > WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
> > > >
> > > > Ilpo, thoughts?
> > > >
> > >
> > > Hmm...
> > >
> > > WARN_ON(idev->mc_list);
> > >
> > > Might be a problem with refcounts somewhere...
> >
> > I have similar warnings in my logs, although its at
> > net/ipv4/devinet.c:136 in my case. Happened altogether three times in
> > the last few days and they all look the same:
> >
> > Nov 5 17:31:35 arch kernel: WARNING: at net/ipv4/devinet.c:136 in_dev_finish_destroy+0x5c/0x90()
> > Nov 5 17:31:35 arch kernel: Hardware name: System Product Name
> > Nov 5 17:31:35 arch kernel: Pid: 0, comm: kworker/0:1 Not tainted 2.6.37-rc1-00027-gff8b16d-dirty #4
> > Nov 5 17:31:35 arch kernel: Call Trace:
> > Nov 5 17:31:35 arch kernel: <IRQ> [<ffffffff8105c9f6>] ? warn_slowpath_common+0x76/0xc0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8141889c>] ? in_dev_finish_destroy+0x5c/0x90
> > Nov 5 17:31:35 arch kernel: [<ffffffff813c49e8>] ? dst_destroy+0x68/0x120
> > Nov 5 17:31:35 arch kernel: [<ffffffff813e888f>] ? dst_rcu_free+0x1f/0x30
> > Nov 5 17:31:35 arch kernel: [<ffffffff81090e0c>] ? __rcu_process_callbacks+0xfc/0x2f0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8109103f>] ? rcu_process_callbacks+0x3f/0x70
> > Nov 5 17:31:35 arch kernel: [<ffffffff810621bc>] ? __do_softirq+0x9c/0x120
> > Nov 5 17:31:35 arch kernel: [<ffffffff81030fc9>] ? timer_interrupt+0x19/0x30
> > Nov 5 17:31:35 arch kernel: [<ffffffff8102ea4c>] ? call_softirq+0x1c/0x30
> > Nov 5 17:31:35 arch kernel: [<ffffffff8103080d>] ? do_softirq+0x4d/0x80
> > Nov 5 17:31:35 arch kernel: [<ffffffff8106232d>] ? irq_exit+0x8d/0x90
> > Nov 5 17:31:35 arch kernel: [<ffffffff810306c7>] ? do_IRQ+0x67/0xe0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8144a153>] ? ret_from_intr+0x0/0xa
> > Nov 5 17:31:35 arch kernel: <EOI> [<ffffffff81035ba0>] ? default_idle+0x20/0x40
> > Nov 5 17:31:35 arch kernel: [<ffffffff81035c12>] ? c1e_idle+0x52/0xf0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8102c12c>] ? cpu_idle+0x4c/0xa0
> > Nov 5 17:31:35 arch kernel: ---[ end trace 143683935de8f41f ]---
> > Nov 5 17:31:35 arch kernel: Freeing alive in_device ffff88011ffba600
> >
>
> Hmm....
>
> Is commit 1f1b9c9990205759aae31b7734b0ede41a867f32 present in your
> kernel ? (fib: fib_result_assign() should not change fib refcounts)
Yes, the last warning happend today on the lastest git kernel (from today).
>
> Could you provide some information ?
>
> ifconfig -a
dummy0 Link encap:Ethernet HWaddr 76:FE:79:D4:80:DF
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr 00:08:54:36:F2:2F
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
RX packets:1945 errors:0 dropped:0 overruns:0 frame:0
TX packets:1450 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1910343 (1.8 Mb) TX bytes:177533 (173.3 Kb)
Interrupt:20 Base address:0x6c00
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:18321 errors:0 dropped:0 overruns:0 frame:0
TX packets:18321 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2200368 (2.0 Mb) TX bytes:2200368 (2.0 Mb)
> ip ro
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
default via 192.168.1.1 dev eth0
--
Markus
^ permalink raw reply
* Re: [PATCH] via-rhine: hardware VLAN support
From: Jesse Gross @ 2010-11-08 20:53 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev, David S. Miller
In-Reply-To: <20101108162132.GA32728@core.hellgate.ch>
On Mon, Nov 8, 2010 at 8:21 AM, Roger Luethi <rl@hellgate.ch> wrote:
> On Fri, 05 Nov 2010 11:31:56 -0700, Jesse Gross wrote:
>> On Fri, Nov 5, 2010 at 3:43 AM, Roger Luethi <rl@hellgate.ch> wrote:
>> > This patch adds VLAN hardware support for Rhine chips.
>>
>> This uses the old interfaces for vlan acceleration. We're working to
>> switch drivers over to use the new methods and the old ones will be
>> going away in the future. It would be great if we can avoid adding
>> more code that uses those interfaces.
>
> Can you point me to a driver that has been switched to use the new methods
> already? Is there some other form of documentation?
bnx2 is an example of a driver that has been converted. The commit
that actually made the change was
7d0fd2117e3d0550d7987b3aff2bfbc0244cf7c6, which should highlight the
differences. A key point is that drivers should no longer reference
vlan groups at all.
^ permalink raw reply
* Re: 2.6.37-rc1-git5 -- WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
From: Miles Lane @ 2010-11-08 20:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Markus Trippelsdorf, paulmck, ilpo.jarvinen, LKML, Len Brown,
netdev
In-Reply-To: <1289249191.2790.3.camel@edumazet-laptop>
# ifconfig -a
eth0 Link encap:Ethernet HWaddr e0:cb:4e:0a:ba:16
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:48
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:720 (720.0 B) TX bytes:720 (720.0 B)
wlan0 Link encap:Ethernet HWaddr 00:1e:64:06:05:96
inet addr:192.168.1.104 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21e:64ff:fe06:596/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:86889 errors:0 dropped:1 overruns:0 frame:0
TX packets:53180 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88241580 (88.2 MB) TX bytes:10132172 (10.1 MB)
# ip ro
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.104 metric 2
169.254.0.0/16 dev wlan0 scope link metric 1000
default via 192.168.1.1 dev wlan0 proto static
On Mon, Nov 8, 2010 at 3:46 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 08 novembre 2010 à 21:42 +0100, Markus Trippelsdorf a écrit :
>> On Mon, Nov 08, 2010 at 09:29:26PM +0100, Eric Dumazet wrote:
>> > Le lundi 08 novembre 2010 à 12:06 -0800, Paul E. McKenney a écrit :
>> > > On Mon, Nov 08, 2010 at 02:56:06PM -0500, Miles Lane wrote:
>> > > > WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
>> > > > Hardware name: UL50VT
>> > > > Modules linked in: ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek
>> > > > snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep snd_mixer_oss
>> > > > snd_seq_dummy snd_pcm snd_seq_oss snd_seq_midi iwlagn snd_rawmidi
>> > > > snd_seq_midi_event snd_seq iwlcore uvcvideo snd_timer mac80211
>> > > > snd_seq_device videodev v4l1_compat v4l2_compat_ioctl32 i915 snd
>> > > > rtc_cmos rtc_core psmouse cfg80211 soundcore drm_kms_helper
>> > > > snd_page_alloc rtc_lib asus_laptop video battery ac sparse_keymap wmi
>> > > > button rfkill processor power_supply led_class usb_storage sg sr_mod
>> > > > sd_mod cdrom atl1c ehci_hcd uhci_hcd thermal thermal_sys hwmon
>> > > > Pid: 0, comm: kworker/0:0 Not tainted 2.6.37-rc1-git5 #10
>> > > > Call Trace:
>> > > > <IRQ> [<ffffffff8103767e>] warn_slowpath_common+0x80/0x98
>> > > > [<ffffffff810376ab>] warn_slowpath_null+0x15/0x17
>> > > > [<ffffffff8130d549>] in_dev_finish_destroy+0x3d/0x6e
>> > > > [<ffffffff8130d58e>] in_dev_put+0x14/0x16
>> > > > [<ffffffff8130d5ab>] inet_rcu_free_ifa+0x1b/0x27
>> > > > [<ffffffff810834a8>] __rcu_process_callbacks+0x1a4/0x2bc
>> > > > [<ffffffff8108363b>] rcu_process_callbacks+0x7b/0x82
>> > > > [<ffffffff8103cb9c>] __do_softirq+0xb8/0x15a
>> > > > [<ffffffff8100394c>] call_softirq+0x1c/0x28
>> > > > [<ffffffff81005637>] do_softirq+0x38/0x81
>> > > > [<ffffffff8103cce9>] irq_exit+0x45/0x94
>> > > > [<ffffffff8101ac1f>] smp_apic_timer_interrupt+0x78/0x86
>> > > > [<ffffffff81003413>] apic_timer_interrupt+0x13/0x20
>> > > > <EOI> [<ffffffff8134aff6>] ? _raw_spin_unlock_irqrestore+0x3c/0x69
>> > > > [<ffffffff81059cb3>] clockevents_notify+0x11e/0x12d
>> > > > [<ffffffffa008e561>] ? acpi_idle_enter_bm+0x236/0x271 [processor]
>> > > > [<ffffffffa008dfce>] lapic_timer_state_broadcast+0x41/0x43 [processor]
>> > > > [<ffffffffa008e588>] acpi_idle_enter_bm+0x25d/0x271 [processor]
>> > > > [<ffffffff8129db30>] cpuidle_idle_call+0x9e/0xda
>> > > > [<ffffffff810012ea>] cpu_idle+0xce/0x10c
>> > > > [<ffffffff81343ce8>] start_secondary+0x1fc/0x205
>> > > > ---[ end trace 1d49bc8ff0266634 ]---
>> > > > Freeing alive in_device ffff88013fe536d0
>> > >
>> > > Ilpo, thoughts?
>> > >
>> >
>> > Hmm...
>> >
>> > WARN_ON(idev->mc_list);
>> >
>> > Might be a problem with refcounts somewhere...
>>
>> I have similar warnings in my logs, although its at
>> net/ipv4/devinet.c:136 in my case. Happened altogether three times in
>> the last few days and they all look the same:
>>
>> Nov 5 17:31:35 arch kernel: WARNING: at net/ipv4/devinet.c:136 in_dev_finish_destroy+0x5c/0x90()
>> Nov 5 17:31:35 arch kernel: Hardware name: System Product Name
>> Nov 5 17:31:35 arch kernel: Pid: 0, comm: kworker/0:1 Not tainted 2.6.37-rc1-00027-gff8b16d-dirty #4
>> Nov 5 17:31:35 arch kernel: Call Trace:
>> Nov 5 17:31:35 arch kernel: <IRQ> [<ffffffff8105c9f6>] ? warn_slowpath_common+0x76/0xc0
>> Nov 5 17:31:35 arch kernel: [<ffffffff8141889c>] ? in_dev_finish_destroy+0x5c/0x90
>> Nov 5 17:31:35 arch kernel: [<ffffffff813c49e8>] ? dst_destroy+0x68/0x120
>> Nov 5 17:31:35 arch kernel: [<ffffffff813e888f>] ? dst_rcu_free+0x1f/0x30
>> Nov 5 17:31:35 arch kernel: [<ffffffff81090e0c>] ? __rcu_process_callbacks+0xfc/0x2f0
>> Nov 5 17:31:35 arch kernel: [<ffffffff8109103f>] ? rcu_process_callbacks+0x3f/0x70
>> Nov 5 17:31:35 arch kernel: [<ffffffff810621bc>] ? __do_softirq+0x9c/0x120
>> Nov 5 17:31:35 arch kernel: [<ffffffff81030fc9>] ? timer_interrupt+0x19/0x30
>> Nov 5 17:31:35 arch kernel: [<ffffffff8102ea4c>] ? call_softirq+0x1c/0x30
>> Nov 5 17:31:35 arch kernel: [<ffffffff8103080d>] ? do_softirq+0x4d/0x80
>> Nov 5 17:31:35 arch kernel: [<ffffffff8106232d>] ? irq_exit+0x8d/0x90
>> Nov 5 17:31:35 arch kernel: [<ffffffff810306c7>] ? do_IRQ+0x67/0xe0
>> Nov 5 17:31:35 arch kernel: [<ffffffff8144a153>] ? ret_from_intr+0x0/0xa
>> Nov 5 17:31:35 arch kernel: <EOI> [<ffffffff81035ba0>] ? default_idle+0x20/0x40
>> Nov 5 17:31:35 arch kernel: [<ffffffff81035c12>] ? c1e_idle+0x52/0xf0
>> Nov 5 17:31:35 arch kernel: [<ffffffff8102c12c>] ? cpu_idle+0x4c/0xa0
>> Nov 5 17:31:35 arch kernel: ---[ end trace 143683935de8f41f ]---
>> Nov 5 17:31:35 arch kernel: Freeing alive in_device ffff88011ffba600
>>
>
> Hmm....
>
> Is commit 1f1b9c9990205759aae31b7734b0ede41a867f32 present in your
> kernel ? (fib: fib_result_assign() should not change fib refcounts)
>
> Could you provide some information ?
>
> ifconfig -a
>
> ip ro
>
> Thanks
>
>
>
^ permalink raw reply
* Re: 2.6.37-rc1-git5 -- WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
From: Eric Dumazet @ 2010-11-08 20:46 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: paulmck, Miles Lane, ilpo.jarvinen, LKML, Len Brown, netdev
In-Reply-To: <20101108204240.GA1585@arch.trippelsdorf.de>
Le lundi 08 novembre 2010 à 21:42 +0100, Markus Trippelsdorf a écrit :
> On Mon, Nov 08, 2010 at 09:29:26PM +0100, Eric Dumazet wrote:
> > Le lundi 08 novembre 2010 à 12:06 -0800, Paul E. McKenney a écrit :
> > > On Mon, Nov 08, 2010 at 02:56:06PM -0500, Miles Lane wrote:
> > > > WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
> > > > Hardware name: UL50VT
> > > > Modules linked in: ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek
> > > > snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep snd_mixer_oss
> > > > snd_seq_dummy snd_pcm snd_seq_oss snd_seq_midi iwlagn snd_rawmidi
> > > > snd_seq_midi_event snd_seq iwlcore uvcvideo snd_timer mac80211
> > > > snd_seq_device videodev v4l1_compat v4l2_compat_ioctl32 i915 snd
> > > > rtc_cmos rtc_core psmouse cfg80211 soundcore drm_kms_helper
> > > > snd_page_alloc rtc_lib asus_laptop video battery ac sparse_keymap wmi
> > > > button rfkill processor power_supply led_class usb_storage sg sr_mod
> > > > sd_mod cdrom atl1c ehci_hcd uhci_hcd thermal thermal_sys hwmon
> > > > Pid: 0, comm: kworker/0:0 Not tainted 2.6.37-rc1-git5 #10
> > > > Call Trace:
> > > > <IRQ> [<ffffffff8103767e>] warn_slowpath_common+0x80/0x98
> > > > [<ffffffff810376ab>] warn_slowpath_null+0x15/0x17
> > > > [<ffffffff8130d549>] in_dev_finish_destroy+0x3d/0x6e
> > > > [<ffffffff8130d58e>] in_dev_put+0x14/0x16
> > > > [<ffffffff8130d5ab>] inet_rcu_free_ifa+0x1b/0x27
> > > > [<ffffffff810834a8>] __rcu_process_callbacks+0x1a4/0x2bc
> > > > [<ffffffff8108363b>] rcu_process_callbacks+0x7b/0x82
> > > > [<ffffffff8103cb9c>] __do_softirq+0xb8/0x15a
> > > > [<ffffffff8100394c>] call_softirq+0x1c/0x28
> > > > [<ffffffff81005637>] do_softirq+0x38/0x81
> > > > [<ffffffff8103cce9>] irq_exit+0x45/0x94
> > > > [<ffffffff8101ac1f>] smp_apic_timer_interrupt+0x78/0x86
> > > > [<ffffffff81003413>] apic_timer_interrupt+0x13/0x20
> > > > <EOI> [<ffffffff8134aff6>] ? _raw_spin_unlock_irqrestore+0x3c/0x69
> > > > [<ffffffff81059cb3>] clockevents_notify+0x11e/0x12d
> > > > [<ffffffffa008e561>] ? acpi_idle_enter_bm+0x236/0x271 [processor]
> > > > [<ffffffffa008dfce>] lapic_timer_state_broadcast+0x41/0x43 [processor]
> > > > [<ffffffffa008e588>] acpi_idle_enter_bm+0x25d/0x271 [processor]
> > > > [<ffffffff8129db30>] cpuidle_idle_call+0x9e/0xda
> > > > [<ffffffff810012ea>] cpu_idle+0xce/0x10c
> > > > [<ffffffff81343ce8>] start_secondary+0x1fc/0x205
> > > > ---[ end trace 1d49bc8ff0266634 ]---
> > > > Freeing alive in_device ffff88013fe536d0
> > >
> > > Ilpo, thoughts?
> > >
> >
> > Hmm...
> >
> > WARN_ON(idev->mc_list);
> >
> > Might be a problem with refcounts somewhere...
>
> I have similar warnings in my logs, although its at
> net/ipv4/devinet.c:136 in my case. Happened altogether three times in
> the last few days and they all look the same:
>
> Nov 5 17:31:35 arch kernel: WARNING: at net/ipv4/devinet.c:136 in_dev_finish_destroy+0x5c/0x90()
> Nov 5 17:31:35 arch kernel: Hardware name: System Product Name
> Nov 5 17:31:35 arch kernel: Pid: 0, comm: kworker/0:1 Not tainted 2.6.37-rc1-00027-gff8b16d-dirty #4
> Nov 5 17:31:35 arch kernel: Call Trace:
> Nov 5 17:31:35 arch kernel: <IRQ> [<ffffffff8105c9f6>] ? warn_slowpath_common+0x76/0xc0
> Nov 5 17:31:35 arch kernel: [<ffffffff8141889c>] ? in_dev_finish_destroy+0x5c/0x90
> Nov 5 17:31:35 arch kernel: [<ffffffff813c49e8>] ? dst_destroy+0x68/0x120
> Nov 5 17:31:35 arch kernel: [<ffffffff813e888f>] ? dst_rcu_free+0x1f/0x30
> Nov 5 17:31:35 arch kernel: [<ffffffff81090e0c>] ? __rcu_process_callbacks+0xfc/0x2f0
> Nov 5 17:31:35 arch kernel: [<ffffffff8109103f>] ? rcu_process_callbacks+0x3f/0x70
> Nov 5 17:31:35 arch kernel: [<ffffffff810621bc>] ? __do_softirq+0x9c/0x120
> Nov 5 17:31:35 arch kernel: [<ffffffff81030fc9>] ? timer_interrupt+0x19/0x30
> Nov 5 17:31:35 arch kernel: [<ffffffff8102ea4c>] ? call_softirq+0x1c/0x30
> Nov 5 17:31:35 arch kernel: [<ffffffff8103080d>] ? do_softirq+0x4d/0x80
> Nov 5 17:31:35 arch kernel: [<ffffffff8106232d>] ? irq_exit+0x8d/0x90
> Nov 5 17:31:35 arch kernel: [<ffffffff810306c7>] ? do_IRQ+0x67/0xe0
> Nov 5 17:31:35 arch kernel: [<ffffffff8144a153>] ? ret_from_intr+0x0/0xa
> Nov 5 17:31:35 arch kernel: <EOI> [<ffffffff81035ba0>] ? default_idle+0x20/0x40
> Nov 5 17:31:35 arch kernel: [<ffffffff81035c12>] ? c1e_idle+0x52/0xf0
> Nov 5 17:31:35 arch kernel: [<ffffffff8102c12c>] ? cpu_idle+0x4c/0xa0
> Nov 5 17:31:35 arch kernel: ---[ end trace 143683935de8f41f ]---
> Nov 5 17:31:35 arch kernel: Freeing alive in_device ffff88011ffba600
>
Hmm....
Is commit 1f1b9c9990205759aae31b7734b0ede41a867f32 present in your
kernel ? (fib: fib_result_assign() should not change fib refcounts)
Could you provide some information ?
ifconfig -a
ip ro
Thanks
^ permalink raw reply
* Re: [PATCH 01/11] vxge: enable rxhash
From: David Miller @ 2010-11-08 20:44 UTC (permalink / raw)
To: jon.mason; +Cc: netdev, sivakumar.subramani, sreenivasa.honnur, ram.vepa
In-Reply-To: <1288911122-28669-1-git-send-email-jon.mason@exar.com>
This patch set doesn't apply at all to the current tree, please
respin them, thanks.
^ permalink raw reply
* Re: 2.6.37-rc1-git5 -- WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
From: Markus Trippelsdorf @ 2010-11-08 20:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: paulmck, Miles Lane, ilpo.jarvinen, LKML, Len Brown, netdev
In-Reply-To: <1289248166.2790.1.camel@edumazet-laptop>
On Mon, Nov 08, 2010 at 09:29:26PM +0100, Eric Dumazet wrote:
> Le lundi 08 novembre 2010 à 12:06 -0800, Paul E. McKenney a écrit :
> > On Mon, Nov 08, 2010 at 02:56:06PM -0500, Miles Lane wrote:
> > > WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
> > > Hardware name: UL50VT
> > > Modules linked in: ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek
> > > snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep snd_mixer_oss
> > > snd_seq_dummy snd_pcm snd_seq_oss snd_seq_midi iwlagn snd_rawmidi
> > > snd_seq_midi_event snd_seq iwlcore uvcvideo snd_timer mac80211
> > > snd_seq_device videodev v4l1_compat v4l2_compat_ioctl32 i915 snd
> > > rtc_cmos rtc_core psmouse cfg80211 soundcore drm_kms_helper
> > > snd_page_alloc rtc_lib asus_laptop video battery ac sparse_keymap wmi
> > > button rfkill processor power_supply led_class usb_storage sg sr_mod
> > > sd_mod cdrom atl1c ehci_hcd uhci_hcd thermal thermal_sys hwmon
> > > Pid: 0, comm: kworker/0:0 Not tainted 2.6.37-rc1-git5 #10
> > > Call Trace:
> > > <IRQ> [<ffffffff8103767e>] warn_slowpath_common+0x80/0x98
> > > [<ffffffff810376ab>] warn_slowpath_null+0x15/0x17
> > > [<ffffffff8130d549>] in_dev_finish_destroy+0x3d/0x6e
> > > [<ffffffff8130d58e>] in_dev_put+0x14/0x16
> > > [<ffffffff8130d5ab>] inet_rcu_free_ifa+0x1b/0x27
> > > [<ffffffff810834a8>] __rcu_process_callbacks+0x1a4/0x2bc
> > > [<ffffffff8108363b>] rcu_process_callbacks+0x7b/0x82
> > > [<ffffffff8103cb9c>] __do_softirq+0xb8/0x15a
> > > [<ffffffff8100394c>] call_softirq+0x1c/0x28
> > > [<ffffffff81005637>] do_softirq+0x38/0x81
> > > [<ffffffff8103cce9>] irq_exit+0x45/0x94
> > > [<ffffffff8101ac1f>] smp_apic_timer_interrupt+0x78/0x86
> > > [<ffffffff81003413>] apic_timer_interrupt+0x13/0x20
> > > <EOI> [<ffffffff8134aff6>] ? _raw_spin_unlock_irqrestore+0x3c/0x69
> > > [<ffffffff81059cb3>] clockevents_notify+0x11e/0x12d
> > > [<ffffffffa008e561>] ? acpi_idle_enter_bm+0x236/0x271 [processor]
> > > [<ffffffffa008dfce>] lapic_timer_state_broadcast+0x41/0x43 [processor]
> > > [<ffffffffa008e588>] acpi_idle_enter_bm+0x25d/0x271 [processor]
> > > [<ffffffff8129db30>] cpuidle_idle_call+0x9e/0xda
> > > [<ffffffff810012ea>] cpu_idle+0xce/0x10c
> > > [<ffffffff81343ce8>] start_secondary+0x1fc/0x205
> > > ---[ end trace 1d49bc8ff0266634 ]---
> > > Freeing alive in_device ffff88013fe536d0
> >
> > Ilpo, thoughts?
> >
>
> Hmm...
>
> WARN_ON(idev->mc_list);
>
> Might be a problem with refcounts somewhere...
I have similar warnings in my logs, although its at
net/ipv4/devinet.c:136 in my case. Happened altogether three times in
the last few days and they all look the same:
Nov 5 17:31:35 arch kernel: WARNING: at net/ipv4/devinet.c:136 in_dev_finish_destroy+0x5c/0x90()
Nov 5 17:31:35 arch kernel: Hardware name: System Product Name
Nov 5 17:31:35 arch kernel: Pid: 0, comm: kworker/0:1 Not tainted 2.6.37-rc1-00027-gff8b16d-dirty #4
Nov 5 17:31:35 arch kernel: Call Trace:
Nov 5 17:31:35 arch kernel: <IRQ> [<ffffffff8105c9f6>] ? warn_slowpath_common+0x76/0xc0
Nov 5 17:31:35 arch kernel: [<ffffffff8141889c>] ? in_dev_finish_destroy+0x5c/0x90
Nov 5 17:31:35 arch kernel: [<ffffffff813c49e8>] ? dst_destroy+0x68/0x120
Nov 5 17:31:35 arch kernel: [<ffffffff813e888f>] ? dst_rcu_free+0x1f/0x30
Nov 5 17:31:35 arch kernel: [<ffffffff81090e0c>] ? __rcu_process_callbacks+0xfc/0x2f0
Nov 5 17:31:35 arch kernel: [<ffffffff8109103f>] ? rcu_process_callbacks+0x3f/0x70
Nov 5 17:31:35 arch kernel: [<ffffffff810621bc>] ? __do_softirq+0x9c/0x120
Nov 5 17:31:35 arch kernel: [<ffffffff81030fc9>] ? timer_interrupt+0x19/0x30
Nov 5 17:31:35 arch kernel: [<ffffffff8102ea4c>] ? call_softirq+0x1c/0x30
Nov 5 17:31:35 arch kernel: [<ffffffff8103080d>] ? do_softirq+0x4d/0x80
Nov 5 17:31:35 arch kernel: [<ffffffff8106232d>] ? irq_exit+0x8d/0x90
Nov 5 17:31:35 arch kernel: [<ffffffff810306c7>] ? do_IRQ+0x67/0xe0
Nov 5 17:31:35 arch kernel: [<ffffffff8144a153>] ? ret_from_intr+0x0/0xa
Nov 5 17:31:35 arch kernel: <EOI> [<ffffffff81035ba0>] ? default_idle+0x20/0x40
Nov 5 17:31:35 arch kernel: [<ffffffff81035c12>] ? c1e_idle+0x52/0xf0
Nov 5 17:31:35 arch kernel: [<ffffffff8102c12c>] ? cpu_idle+0x4c/0xa0
Nov 5 17:31:35 arch kernel: ---[ end trace 143683935de8f41f ]---
Nov 5 17:31:35 arch kernel: Freeing alive in_device ffff88011ffba600
--
Markus
^ permalink raw reply
* Re: 2.6.37-rc1-git5 -- WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
From: Eric Dumazet @ 2010-11-08 20:29 UTC (permalink / raw)
To: paulmck; +Cc: Miles Lane, ilpo.jarvinen, LKML, Len Brown, netdev
In-Reply-To: <20101108200600.GG4032@linux.vnet.ibm.com>
Le lundi 08 novembre 2010 à 12:06 -0800, Paul E. McKenney a écrit :
> On Mon, Nov 08, 2010 at 02:56:06PM -0500, Miles Lane wrote:
> > WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
> > Hardware name: UL50VT
> > Modules linked in: ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek
> > snd_hda_intel snd_hda_codec snd_pcm_oss snd_hwdep snd_mixer_oss
> > snd_seq_dummy snd_pcm snd_seq_oss snd_seq_midi iwlagn snd_rawmidi
> > snd_seq_midi_event snd_seq iwlcore uvcvideo snd_timer mac80211
> > snd_seq_device videodev v4l1_compat v4l2_compat_ioctl32 i915 snd
> > rtc_cmos rtc_core psmouse cfg80211 soundcore drm_kms_helper
> > snd_page_alloc rtc_lib asus_laptop video battery ac sparse_keymap wmi
> > button rfkill processor power_supply led_class usb_storage sg sr_mod
> > sd_mod cdrom atl1c ehci_hcd uhci_hcd thermal thermal_sys hwmon
> > Pid: 0, comm: kworker/0:0 Not tainted 2.6.37-rc1-git5 #10
> > Call Trace:
> > <IRQ> [<ffffffff8103767e>] warn_slowpath_common+0x80/0x98
> > [<ffffffff810376ab>] warn_slowpath_null+0x15/0x17
> > [<ffffffff8130d549>] in_dev_finish_destroy+0x3d/0x6e
> > [<ffffffff8130d58e>] in_dev_put+0x14/0x16
> > [<ffffffff8130d5ab>] inet_rcu_free_ifa+0x1b/0x27
> > [<ffffffff810834a8>] __rcu_process_callbacks+0x1a4/0x2bc
> > [<ffffffff8108363b>] rcu_process_callbacks+0x7b/0x82
> > [<ffffffff8103cb9c>] __do_softirq+0xb8/0x15a
> > [<ffffffff8100394c>] call_softirq+0x1c/0x28
> > [<ffffffff81005637>] do_softirq+0x38/0x81
> > [<ffffffff8103cce9>] irq_exit+0x45/0x94
> > [<ffffffff8101ac1f>] smp_apic_timer_interrupt+0x78/0x86
> > [<ffffffff81003413>] apic_timer_interrupt+0x13/0x20
> > <EOI> [<ffffffff8134aff6>] ? _raw_spin_unlock_irqrestore+0x3c/0x69
> > [<ffffffff81059cb3>] clockevents_notify+0x11e/0x12d
> > [<ffffffffa008e561>] ? acpi_idle_enter_bm+0x236/0x271 [processor]
> > [<ffffffffa008dfce>] lapic_timer_state_broadcast+0x41/0x43 [processor]
> > [<ffffffffa008e588>] acpi_idle_enter_bm+0x25d/0x271 [processor]
> > [<ffffffff8129db30>] cpuidle_idle_call+0x9e/0xda
> > [<ffffffff810012ea>] cpu_idle+0xce/0x10c
> > [<ffffffff81343ce8>] start_secondary+0x1fc/0x205
> > ---[ end trace 1d49bc8ff0266634 ]---
> > Freeing alive in_device ffff88013fe536d0
>
> Ilpo, thoughts?
>
Hmm...
WARN_ON(idev->mc_list);
Might be a problem with refcounts somewhere...
Miles, is it reproductible ?
Thanks
^ permalink raw reply
* Re: Using Netfiletr hooks without IP stack
From: Jan Engelhardt @ 2010-11-08 20:23 UTC (permalink / raw)
To: Yedidia Amit; +Cc: Netfilter Developer Mailing List, netdev
In-Reply-To: <A50724DAD8873141837C64A73A73735F052DD9@mailesl2.esl.corp.elbit.co.il>
On Monday 2010-11-08 07:32, Yedidia Amit wrote:
>Hi All,
>
>I want to use the netfilter framework on my system (running linux
>2.6.33)
>My purpose is to capture and manipulate IP packets. The catch is that I
>am working without the IP stack, so I need to capture the packets in the
>Ethernet layer. I have BSD sockets but the TCP/IP is removed from the
>menuconfig
>
>Are there any hooks which are available for me on that level, or should
>I add some new ones?
That would leave you with af_packet (only).
--
By replying, your organization agrees to relinquish control over future
messages posted in public places such as these, and grant everybody a
worldwide irrevocable right to do with it however they please. The right
to claim sending in error is waived. If you don't accept these terms,
don't post.
^ permalink raw reply
* Re: [PATCH] rds: Fix rds message leak in rds_message_map_pages
From: David Miller @ 2010-11-08 20:20 UTC (permalink / raw)
To: andy.grover; +Cc: xemul, rds-devel, netdev
In-Reply-To: <4CD85245.9090409@oracle.com>
From: Andy Grover <andy.grover@oracle.com>
Date: Mon, 08 Nov 2010 11:40:53 -0800
> On 11/08/2010 08:20 AM, Pavel Emelyanov wrote:
>> The sgs allocation error path leaks the allocated message.
>>
>> Signed-off-by: Pavel Emelyanov<xemul@openvz.org>
...
> Acked-by: Andy Grover <andy.grover@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] pktgen: correct uninitialized queue_map
From: David Miller @ 2010-11-08 20:19 UTC (permalink / raw)
To: junchangwang
Cc: robert.olsson, eric.dumazet, joe, andy.shevchenko, backyes,
netdev
In-Reply-To: <20101108091941.GB5025@Desktop-Junchang>
From: Junchang Wang <junchangwang@gmail.com>
Date: Mon, 8 Nov 2010 17:19:43 +0800
>
> This fix a bug reported by backyes.
> Right the first time pktgen's using queue_map that's not been initialized
> by set_cur_queue_map(pkt_dev);
>
> Signed-off-by: Junchang Wang <junchangwang@gmail.com>
> Signed-off-by: Backyes <backyes@mail.ustc.edu.cn>
Applied, thank you.
I think I added this bug :-)
^ permalink raw reply
* Re: [PATCH 2/2] net: Detect and ignore netif_stop_queue() calls before register_netdev()
From: David Miller @ 2010-11-08 20:19 UTC (permalink / raw)
To: guichaz; +Cc: netdev
In-Reply-To: <1289061572-5029-2-git-send-email-guichaz@gmail.com>
From: Guillaume Chazarain <guichaz@gmail.com>
Date: Sat, 6 Nov 2010 17:39:32 +0100
> After e6484930d7c73d324bccda7d43d131088da697b9: net: allocate tx queues in register_netdevice
> These calls make net drivers oops at load time, so let's avoid people
> git-bisect'ing known problems.
>
> Signed-off-by: Guillaume Chazarain <guichaz@gmail.com>
Applied, but I'd like to remove this check after we've had some
time to weed out all of the offending cases, since this sits
in a hot path of sorts.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] skge: Remove tx queue stopping in skge_devinit()
From: David Miller @ 2010-11-08 20:19 UTC (permalink / raw)
To: guichaz; +Cc: netdev
In-Reply-To: <1289061572-5029-1-git-send-email-guichaz@gmail.com>
From: Guillaume Chazarain <guichaz@gmail.com>
Date: Sat, 6 Nov 2010 17:39:31 +0100
> After e6484930d7c73d324bccda7d43d131088da697b9: net: allocate tx queues in register_netdevice
> It causes an Oops at skge_probe() time.
>
> Signed-off-by: Guillaume Chazarain <guichaz@gmail.com>
Applied.
^ 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