* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-08 17:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev, linux-kernel, Tejun Heo
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)
>
> Following is working for me
>
> echo 16384>/proc/sys/net/ipv6/route/max_size
> modprobe dummy numdummies=2000
> for a in `seq 1 1999`
> do
> ip -6 add add 4444::444:$a/24 dev dummy$a
> done
>
> ip -6 ro | wc -l
> 6008
That helps. I'm getting all of the IP addrs set now, but
having trouble with some of the default gateways (I have one
routing table per interface).
./local/sbin/ip -6 route replace default via 2002:9:8::1 dev eth7#458 table 726
RTNETLINK answers: No buffer space available
dmesg is full of this:
[247106.294743] ipv6: Neighbour table overflow.
A quick look in /proc didn't show a tunable for this, but I'll
go grub through the code.
As for the route/max_size, it would be nice to see some useful kernel
message in dmesg when this hit. Just telling the user '-ENOMEM'
is not at all sufficient to help them figure out the problem.
For that matter, why is there such a limit anyway? IPv4 doesn't appear
to have any such limit?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-08 17:55 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <4CD83752.1070501@candelatech.com>
Le lundi 08 novembre 2010 à 09:45 -0800, Ben Greear a écrit :
> That helps. I'm getting all of the IP addrs set now, but
> having trouble with some of the default gateways (I have one
> routing table per interface).
>
> ./local/sbin/ip -6 route replace default via 2002:9:8::1 dev eth7#458 table 726
> RTNETLINK answers: No buffer space available
>
> dmesg is full of this:
>
> [247106.294743] ipv6: Neighbour table overflow.
>
>
> A quick look in /proc didn't show a tunable for this, but I'll
> go grub through the code.
>
> As for the route/max_size, it would be nice to see some useful kernel
> message in dmesg when this hit. Just telling the user '-ENOMEM'
> is not at all sufficient to help them figure out the problem.
Sure, patches are welcomed. Apparently nobody yet used ipv6 with so many
devices / routes, and this nobody contributed to extend limits.
>
> For that matter, why is there such a limit anyway? IPv4 doesn't appear
> to have any such limit?
There are limits for ipv4, much bigger, you probably never noticed.
/proc/sys/net/ipv4/route/gc_elasticity:8
/proc/sys/net/ipv4/route/gc_interval:60
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:500
/proc/sys/net/ipv4/route/gc_thresh:131072
/proc/sys/net/ipv4/route/gc_timeout:300
/proc/sys/net/ipv4/route/max_size:2097152 <<< HERE
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:2
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:2048
I suggest followup discussion can got to netdev only, now per-cpu it not
anymore the problem ?
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-08 18:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev
In-Reply-To: <1289238912.3167.4.camel@edumazet-laptop>
On 11/08/2010 09:55 AM, Eric Dumazet wrote:
> Le lundi 08 novembre 2010 à 09:45 -0800, Ben Greear a écrit :
>
>> That helps. I'm getting all of the IP addrs set now, but
>> having trouble with some of the default gateways (I have one
>> routing table per interface).
>>
>> ./local/sbin/ip -6 route replace default via 2002:9:8::1 dev eth7#458 table 726
>> RTNETLINK answers: No buffer space available
>>
>> dmesg is full of this:
>>
>> [247106.294743] ipv6: Neighbour table overflow.
>>
>>
>> A quick look in /proc didn't show a tunable for this, but I'll
>> go grub through the code.
>>
>> As for the route/max_size, it would be nice to see some useful kernel
>> message in dmesg when this hit. Just telling the user '-ENOMEM'
>> is not at all sufficient to help them figure out the problem.
>
> Sure, patches are welcomed. Apparently nobody yet used ipv6 with so many
> devices / routes, and this nobody contributed to extend limits.
I'll see what I can do. I'm aiming for several thousand IPv6 addrs,
so will try to get these limitations ironed out.
>> For that matter, why is there such a limit anyway? IPv4 doesn't appear
>> to have any such limit?
>
> There are limits for ipv4, much bigger, you probably never noticed.
>
>
> /proc/sys/net/ipv4/route/gc_elasticity:8
> /proc/sys/net/ipv4/route/gc_interval:60
> /proc/sys/net/ipv4/route/gc_min_interval:0
> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
> /proc/sys/net/ipv4/route/gc_thresh:131072
> /proc/sys/net/ipv4/route/gc_timeout:300
> /proc/sys/net/ipv4/route/max_size:2097152<<< HERE
> /proc/sys/net/ipv4/route/min_adv_mss:256
> /proc/sys/net/ipv4/route/min_pmtu:552
> /proc/sys/net/ipv4/route/mtu_expires:600
> /proc/sys/net/ipv4/route/redirect_load:2
> /proc/sys/net/ipv4/route/redirect_number:9
> /proc/sys/net/ipv4/route/redirect_silence:2048
>
> I suggest followup discussion can got to netdev only, now per-cpu it not
> anymore the problem ?
Agreed, and trimmed.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev
From: Matt Domsch @ 2010-11-08 18:17 UTC (permalink / raw)
To: Sujit K M
Cc: Greg KH, K, Narendra, linux-hotplug@vger.kernel.org,
netdev@vger.kernel.org, Hargrave, Jordan, Rose, Charles
In-Reply-To: <AANLkTin_rswTZn5RxH375u4xsoftQzMSPMRfUvy77fdX@mail.gmail.com>
On Mon, Nov 08, 2010 at 02:12:56PM +0530, Sujit K M wrote:
> > At Linux Plumbers Conference today, this problem space was discussed
> > once again, and I believe concensus on approach was reached. ?Here
> > goes:
>
> Was the patch a starting point for the discussion.
The discussion has been ongoing for 3 years. This patch was posted
just prior to the conversation at LPC, where aspects of this patch
(reading values from sysfs and using them, if present) were discussed
at length. The patch itself will have to undergo some changes based
on the outcome of that discussion.
> > * If a 70-persistent-net.rules file sets a name, honor that. ?This
> > ?preserves existing installs.
> >
> > * If BIOS provides indexes for onboard devices, honor that.
> > ** Rename onboard NICs "lom[1-N]" as BIOS reports (# matches chassis labels)
> > ** No rename for all others "ethX" (no change for NICs in PCI slots/USB/others)
> >
> > * If neither are true, do not rename at all.
>
> I would like to know what is the difference in the nomenclature for this.
LOM == "LAN on Motherboard", aka "Embedded NIC". I'm not wedded to
using "lomX", but it can't be ethX, and it must be short, and that's
as good as anything.
> > * Implementation will be:
> > ** Udev rules to be included in upstream udev will read the index
> > ? value from sysfs (provided by SMBIOS 2.6 info on kernels >= 2.6.36,
> > ? PCI DSM info at some future point) if present, and rename LOMs
> > ? based on that index value. ?Distros will use these rules by default
> > ? (Ubuntu and Fedora maintainers on board with the concept; I have
> > ? not spoken with other distros yet.)
> > ** Legacy distros with older udev rules will invoke biosdevname on
> > ? kernels < 2.6.36 to get the same information, if present, and will
> > ? rename LOMs based on index value.
>
> How will you manage these scenarios.
I've had conversations with the relevant maintainers of the subsystems
of each of the major distributions. What else are you looking for please?
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [PATCH 1/2] docs: Add neigh/gc_thresh3 and route/max_size documentation.
From: Ben Greear @ 2010-11-08 19:13 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 f350c69... 7c5cca2... M Documentation/networking/ip-sysctl.txt
Documentation/networking/ip-sysctl.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f350c69..7c5cca2 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -20,6 +20,15 @@ ip_no_pmtu_disc - BOOLEAN
min_pmtu - INTEGER
default 562 - minimum discovered Path MTU
+route/max_size - INTEGER
+ Maximum number of routes allowed in the kernel. Increase
+ this when using large numbers of interfaces and/or routes.
+
+neigh/default/gc_thresh3 - INTEGER
+ Maximum number of neighbor entries allowed. Increase this
+ when using large numbers of interfaces and when communicating
+ with large numbers of directly-connected peers.
+
mtu_expires - INTEGER
Time, in seconds, that cached PMTU information is kept.
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/2] IPv6: Warn users when route/max_entries is reached.
From: Ben Greear @ 2010-11-08 19:13 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
In-Reply-To: <1289243629-20789-1-git-send-email-greearb@candelatech.com>
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);
--
1.6.2.5
^ permalink raw reply related
* Re: Netlink limitations
From: Jan Engelhardt @ 2010-11-08 19:21 UTC (permalink / raw)
To: Thomas Graf; +Cc: Patrick McHardy, David S. Miller, pablo, netdev
In-Reply-To: <20101108151635.GA20629@canuck.infradead.org>
On Monday 2010-11-08 16:16, Thomas Graf wrote:
>>
>> Messages are not limited to 64k, individual attributes are. Holger
>> started working on a nlattr32, which uses 32 bit for the length
>> value.
>
>Also, it is not required to pack everything in attributes. Your protocol
>may specify that the whole message payload consists of chained attributes.
>Alternatively you may as well split your attribut chain and dump them
>as several messages.
Yeah with NETLINK_URELEASE that seems the way to go. However, what are
compelling arguments to use Netlink over other forms of bidirectional
communication? (To play devils advocate, one could use nlattr32/TLVs
over ioctl too.)
^ permalink raw reply
* Re: [PATCH] rds: Fix rds message leak in rds_message_map_pages
From: Andy Grover @ 2010-11-08 19:40 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, rds-devel, Linux Netdev List
In-Reply-To: <4CD82362.9070402@parallels.com>
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>
>
> ---
>
> diff --git a/net/rds/message.c b/net/rds/message.c
> index 848cff4..1fd3d29 100644
> --- a/net/rds/message.c
> +++ b/net/rds/message.c
> @@ -249,8 +249,10 @@ struct rds_message *rds_message_map_pages(unsigned long *page_addrs, unsigned in
> rm->m_inc.i_hdr.h_len = cpu_to_be32(total_len);
> rm->data.op_nents = ceil(total_len, PAGE_SIZE);
> rm->data.op_sg = rds_message_alloc_sgs(rm, num_sgs);
> - if (!rm->data.op_sg)
> + if (!rm->data.op_sg) {
> + rds_message_put(rm);
> return ERR_PTR(-ENOMEM);
> + }
>
> for (i = 0; i< rm->data.op_nents; ++i) {
> sg_set_page(&rm->data.op_sg[i],
Acked-by: Andy Grover <andy.grover@oracle.com>
-- Andy
^ permalink raw reply
* Re: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
From: Jesse Gross @ 2010-11-08 19:59 UTC (permalink / raw)
To: Duyck, Alexander H
Cc: Kirsher, Jeffrey T, David Miller, netdev@vger.kernel.org,
Brandeburg, Jesse
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F25BD180E03@orsmsx501.amr.corp.intel.com>
On Fri, Nov 5, 2010 at 3:30 PM, Duyck, Alexander H
<alexander.h.duyck@intel.com> wrote:
>
>
>>-----Original Message-----
>>From: Kirsher, Jeffrey T
>>Sent: Friday, November 05, 2010 1:07 PM
>>To: Jesse Gross
>>Cc: David Miller; netdev@vger.kernel.org; Brandeburg, Jesse; Duyck,
>>Alexander H
>>Subject: Re: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
>>
>>On Fri, 2010-11-05 at 12:56 -0700, Jesse Gross wrote:
>>> On Fri, Nov 5, 2010 at 12:11 PM, Jeff Kirsher
>>> <jeffrey.t.kirsher@intel.com> wrote:
>>> > On Sat, 2010-10-30 at 11:49 -0700, Jesse Gross wrote:
>>> >> On transmit, the ixgb driver will only use vlan acceleration if a
>>> >> vlan group is configured. This can lead to tags getting dropped
>>> >> when bridging because the networking core assumes that a driver
>>> >> that claims vlan acceleration support can do it at all times.
>>This
>>> >> change should have been part of commit eab6d18d "vlan: Don't
>>check for
>>> >> vlan group before vlan_tx_tag_present." but was missed.
>>> >>
>>> >> Signed-off-by: Jesse Gross <jesse@nicira.com>
>>> >> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> >> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
>>> >> CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>>> >> ---
>>> >> drivers/net/ixgb/ixgb_main.c | 2 +-
>>> >> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> >>
>>> >> diff --git a/drivers/net/ixgb/ixgb_main.c
>>b/drivers/net/ixgb/ixgb_main.c
>>> >> index caa8192..d18194e 100644
>>> >> --- a/drivers/net/ixgb/ixgb_main.c
>>> >> +++ b/drivers/net/ixgb/ixgb_main.c
>>> >> @@ -1498,7 +1498,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct
>>net_device *netdev)
>>> >> DESC_NEEDED)))
>>> >> return NETDEV_TX_BUSY;
>>> >>
>>> >> - if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
>>> >> + if (vlan_tx_tag_present(skb)) {
>>> >> tx_flags |= IXGB_TX_FLAGS_VLAN;
>>> >> vlan_id = vlan_tx_tag_get(skb);
>>> >> }
>>> >
>>> > After further review, NAK because this will cause a bug. With
>>this
>>> > patch it would be possible to overrun the buffers, so the correct
>>fix is
>>> > to increase max_frame_size by VLAN_TAG_SIZE in
>>ixgb/igb_change_mtu.
>>>
>>> Hmm, I didn't see any other place where it made changes to the
>>> handling of packets on transmit if a vlan group is configured.
>>Maybe
>>> the buffer is extended when a group is registered and stripping is
>>> enabled?
>>>
>>> In any case, you might want to check the other Intel drivers for
>>> similar problems. I did a pass and made a mass conversion of this
>>> type a little while ago. Those changes have already been merged, I
>>> just missed this one by accident.
>>
>>I will get with Alex and review the other Intel drivers, thanks Jesse.
>
> Just to make things clear. The ixgb patch is fine. There isn't anything wrong with it.
>
> The patch with the bug is the other patch, "2/2 igb: Don't depend on VLAN group for receive size". The problem is it was updating the RLPML register, but not updating the buffer sizes as such there were a few cases where we could receive a buffer larger the SKB head room. The bug itself probably won't come up very often since there are only a couple of very specific MTU sizes where it will be an issue.
>
OK, that makes more sense. It seems that the other drivers already
account for this, so they should be fine.
> The quick fix for your patch is to move the addition of VLAN_TAG_SIZE to the max_frame in igb_change_mtu instead of in the set_rlpml call. Otherwise I will see about submitting an updated patch in the next few days.
I happy to let you take care of it - obviously you know the
driver/hardware much better than I.
^ permalink raw reply
* Re: 2.6.37-rc1-git5 -- WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
From: Paul E. McKenney @ 2010-11-08 20:06 UTC (permalink / raw)
To: Miles Lane, ilpo.jarvinen; +Cc: LKML, Len Brown, netdev
In-Reply-To: <AANLkTinVyf4CpxdzEWUn7zTyOrAMKY3H9Dct-HfopiSD@mail.gmail.com>
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?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 1/2] solos: Add 'Firmware' attribute for Traverse overall firmware version
From: David Miller @ 2010-11-08 20:18 UTC (permalink / raw)
To: dwmw2; +Cc: netdev
In-Reply-To: <1288643669.5977.21.camel@macbook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Mon, 01 Nov 2010 16:34:29 -0400
> The existing 'FirmwareVersion' attribute only covers the DSP firmware as
> provided by Conexant; not the overall version of the device firmware. We
> do want to be able to see the full version number too.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] solos: Refuse to upgrade firmware with older FPGA. It doesn't work.
From: David Miller @ 2010-11-08 20:18 UTC (permalink / raw)
To: dwmw2; +Cc: netdev
In-Reply-To: <1288643728.5977.22.camel@macbook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Mon, 01 Nov 2010 16:35:28 -0400
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] classifier: report statistics for basic classifier
From: David Miller @ 2010-11-08 20:18 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20101104174704.573c52e4@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 4 Nov 2010 17:47:04 -0400
> The basic classifier keeps statistics but does not report it to user space.
> This showed up when using basic classifier (with police) as a default catch
> all on ingress; no statistics were reported.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: fix overlap check for fragments
From: David Miller @ 2010-11-08 20:19 UTC (permalink / raw)
To: shanwei; +Cc: nicolas.dichtel, netdev, kaber
In-Reply-To: <4CD3F0F2.2080804@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 05 Nov 2010 19:56:34 +0800
> The type of FRAG6_CB(prev)->offset is int, skb->len is *unsigned* int,
> and offset is int.
>
> Without this patch, type conversion occurred to this expression, when
> (FRAG6_CB(prev)->offset + prev->len) is less than offset.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Applied.
^ 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
* 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] 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] 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: 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: 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: 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: [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: 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: 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: [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
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