* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: David Miller @ 2010-06-02 17:31 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <20100602.101258.134121018.davem@davemloft.net>
Just in case people are really so clueless as to be unable to figure
this out:
echo 1 >/sys/kernel/debug/tracing/events/skb/kfree_skb/enable
...do some stuff...
cat /sys/kernel/debug/tracing/trace
You can even trace it using 'perf' by passing "skb:kfree_skb"
as the event specifier.
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts
From: David Miller @ 2010-06-02 17:26 UTC (permalink / raw)
To: geert; +Cc: fthain, joe, netdev, linux-kernel, linux-m68k
In-Reply-To: <AANLkTilqknhgBCXd-5Yxj9U8gDzDfMmmZdwDOvf-8kbH@mail.gmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed, 2 Jun 2010 19:24:08 +0200
> On Sat, May 29, 2010 at 10:03, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Fri, May 28, 2010 at 19:21, Finn Thain <fthain@telegraphics.com.au> wrote:
>>> On Sun, 23 May 2010, Geert Uytterhoeven wrote:
>>>> >> But here's a better solution. I do not have the hardware to test it,
>>>> >> though. Finn, does it {look OK,work}?
>>>> >
>>>> > It looks fine. I can't test it right now, but I will do so when I get
>>>> > the opportunity.
>>>>
>>>> Any news from the test front?
>>>
>>> This is commit ba0f916ca7ac79356e2ed32a85c3aa8255b104e7, right?
>>
>> Yep.
>>
>>> If so, it tests OK here.
>>
>> Thanks for testing!
>
> David, will you take this one too?
Please post a fresh copy, there is no way that sucker still applies cleanly
as there have been some changes in this area recently.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Geert Uytterhoeven @ 2010-06-02 17:24 UTC (permalink / raw)
To: Finn Thain
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <AANLkTilLXOSb2P_m4uUubmJar2VMFXizzpa_mQ1j8GPz@mail.gmail.com>
On Sat, May 29, 2010 at 10:03, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, May 28, 2010 at 19:21, Finn Thain <fthain@telegraphics.com.au> wrote:
>> On Sun, 23 May 2010, Geert Uytterhoeven wrote:
>>> >> But here's a better solution. I do not have the hardware to test it,
>>> >> though. Finn, does it {look OK,work}?
>>> >
>>> > It looks fine. I can't test it right now, but I will do so when I get
>>> > the opportunity.
>>>
>>> Any news from the test front?
>>
>> This is commit ba0f916ca7ac79356e2ed32a85c3aa8255b104e7, right?
>
> Yep.
>
>> If so, it tests OK here.
>
> Thanks for testing!
David, will you take this one too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 17:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275498007.3915.20.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 09:43 -0700, Eric W. Biederman wrote:
>
>> > Hmm. I'm also not seeing it with veth, it would seem that ought to be
>> > similar?
>>
>> Since it is the register_netdev path it should be exactly the same.
>>
>> The big change I made is I in some instances I replaced
>> sysfs_remove_link with sysfs_delete_link so I could have enough
>> information to infer which network namespace the link was in. Since
>> wlan0 is a netdevice all of that information should already be there.
>
> I have no idea :)
>
>> > I don't know if that's happening .. just guessing that it might cause
>> > such a problem, and maybe some things are deferred somehow? Since netdev
>> > destruction can be deferred, but the wifi sysfs destruction isn't. But
>> > then that link there should cause the refcount to not go down until the
>> > link goes away>?
>>
>> unregister_netdevice will defer the final destruction but it does not
>> defer netdev_unregister_kobject -> device_del.
>>
>> What happens if in exit_mac80211_hwsim you call unregister_netdev before
>> mac80211_hwsim_free?
>>
>> At a quick glance it simply looks like you have the ordering reversed in your
>> module cleanup, and this is not network namespace related at all.
>
> Nah, the unregister_netdev there removes the "hwsim0" device, while the
> mac80211_hwsim_free() will remove all the others, so the ordering of
> those two doesn't matter.
So far that hypothesis that the target of the symlink is being removed before
the actual actual link looks like it could cause this.
Are there any other left overs in sysfs, besides just /sys/class/net/wlan0?
Eric
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 17:19 UTC (permalink / raw)
To: David Miller; +Cc: cl, netdev, shemminger, Neil Horman
In-Reply-To: <20100602.101258.134121018.davem@davemloft.net>
Le mercredi 02 juin 2010 à 10:12 -0700, David Miller a écrit :
> From: Christoph Lameter <cl@linux-foundation.org>
> Date: Wed, 2 Jun 2010 11:49:18 -0500 (CDT)
>
> > On Wed, 2 Jun 2010, Eric Dumazet wrote:
> >
> >> take a look at
> >>
> >> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
> >
> > System tap?
>
> You don't need to use system tap, just the normal tracing stuff using
> sysfs files suffices.
>
It would be good if Neil could gave us a man page or something ;)
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: David Miller @ 2010-06-02 17:12 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021140320.30182@router.home>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 2 Jun 2010 11:49:18 -0500 (CDT)
> On Wed, 2 Jun 2010, Eric Dumazet wrote:
>
>> take a look at
>>
>> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
>
> System tap?
You don't need to use system tap, just the normal tracing stuff using
sysfs files suffices.
^ permalink raw reply
* Re: [PATCH] net/core: Save the port number a netdevice uses
From: David Miller @ 2010-06-02 17:12 UTC (permalink / raw)
To: bhutchings-s/n/eUQHGBpZroRs9YW3xA
Cc: eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rdreier-FYB4Gu1CFyUAvxtiuMwx3w, yevgenyp-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <1275496949.2115.18.camel-xQnnTUlwzDrdvaEqJLTMTA9jg9n5Vt1AMm0uRHvK7Nw@public.gmane.org>
From: Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
Date: Wed, 02 Jun 2010 17:42:29 +0100
> On Wed, 2010-05-26 at 02:16 -0700, David Miller wrote:
>> From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
>> Date: Wed, 26 May 2010 12:08:52 +0300
>>
>> > So if I understand you correctly, you think that I should not bother
>> > to set a default value of 1. Each driver that cares about the value
>> > of this field, will set it however they want.
>>
>> I actually mean that the value "0" should mean the first port,
>> the value "1" should mean the second port, etc.
>
> There's a compatibility problem here though: when user-space looks at
> this number it can't tell whether "0" really means the first port or
> that the driver isn't setting dev_id.
That's perfect, it means we don't have to add explicit settings to
drivers which driver only one port. Ie. the vast majority of
cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 17:00 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev
In-Reply-To: <m14ohlxu51.fsf@fess.ebiederm.org>
On Wed, 2010-06-02 at 09:43 -0700, Eric W. Biederman wrote:
> > Hmm. I'm also not seeing it with veth, it would seem that ought to be
> > similar?
>
> Since it is the register_netdev path it should be exactly the same.
>
> The big change I made is I in some instances I replaced
> sysfs_remove_link with sysfs_delete_link so I could have enough
> information to infer which network namespace the link was in. Since
> wlan0 is a netdevice all of that information should already be there.
I have no idea :)
> > I don't know if that's happening .. just guessing that it might cause
> > such a problem, and maybe some things are deferred somehow? Since netdev
> > destruction can be deferred, but the wifi sysfs destruction isn't. But
> > then that link there should cause the refcount to not go down until the
> > link goes away>?
>
> unregister_netdevice will defer the final destruction but it does not
> defer netdev_unregister_kobject -> device_del.
>
> What happens if in exit_mac80211_hwsim you call unregister_netdev before
> mac80211_hwsim_free?
>
> At a quick glance it simply looks like you have the ordering reversed in your
> module cleanup, and this is not network namespace related at all.
Nah, the unregister_netdev there removes the "hwsim0" device, while the
mac80211_hwsim_free() will remove all the others, so the ordering of
those two doesn't matter.
johannes
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, shemminger
In-Reply-To: <1275496439.2725.203.camel@edumazet-laptop>
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> take a look at
>
> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
System tap? Oh no. Also skbs may be freed for legitimate reasons. The
point is that the loss detection needs to be usable for a regular mortal.
With the counters in /proc/net/snmp you have something that is easy to
handle.
The approach with systemtap will need lots of work to both get the tracing
environment setup (local competence in systemtap) and participation by a
developer to figure out what the output means. Then there is also the
additional code overhead that you do not want by default in the kernel. So
we would need a different kernel for diagnostics.
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 16:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275495677.3915.16.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 09:17 -0700, Eric W. Biederman wrote:
>
>> >> Ah, so the network devices aren't getting removed?
>> >
>> > Well the netdevs are gone, just the links aren't going away. the
>> > mac80211_hwsim directory is gone too.
>> >
>> >> Do you have network namespaces enabled in your kernel or disabled?
>> >
>> > enabled
>> >
>> >> And this is 2.6.35-rc1, right?
>> >
>> > yes.
>> >
>> > Come to think of it, maybe somehow it ends up removing
>> > mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
>> > guess I could make it print messages about that somehow?
>>
>> The wireless drivers are a little different, and come to think of it
>> network namespace support has been added to the wireless drivers since
>> last I looked closely.
>
> Yeah, I now need to go add tagged sysfs support to it too.
>
>> Do you know what creates/deletes these links?
>> Is it the normal register_netdevice -> device_add path?
>
> Yes, they aren't done specially.
>> I definitely changed the symlink code a little making things network namespace
>> aware so it is reasonable to assume that something in my changes affected the
>> wireless drivers.
>
>> I took a quick look and with my patches against 2.6.33 I'm not seeing this.
>
> Hmm. I'm also not seeing it with veth, it would seem that ought to be
> similar?
Since it is the register_netdev path it should be exactly the same.
The big change I made is I in some instances I replaced
sysfs_remove_link with sysfs_delete_link so I could have enough
information to infer which network namespace the link was in. Since
wlan0 is a netdevice all of that information should already be there.
>> I take a closer look at 2.6.35-rc1 and see if I can figure out what is
>> going on. It would definitely be wrong if hwsim0 is removed before
>> wlan0.
>
> I don't know if that's happening .. just guessing that it might cause
> such a problem, and maybe some things are deferred somehow? Since netdev
> destruction can be deferred, but the wifi sysfs destruction isn't. But
> then that link there should cause the refcount to not go down until the
> link goes away>?
unregister_netdevice will defer the final destruction but it does not
defer netdev_unregister_kobject -> device_del.
What happens if in exit_mac80211_hwsim you call unregister_netdev before
mac80211_hwsim_free?
At a quick glance it simply looks like you have the ordering reversed in your
module cleanup, and this is not network namespace related at all.
Eric
^ permalink raw reply
* Re: [PATCH] net/core: Save the port number a netdevice uses
From: Ben Hutchings @ 2010-06-02 16:42 UTC (permalink / raw)
To: David Miller
Cc: Eli Cohen, netdev, linux-rdma, Roland Dreier, Yevgeny Petrilin
In-Reply-To: <20100526.021635.179940939.davem@davemloft.net>
On Wed, 2010-05-26 at 02:16 -0700, David Miller wrote:
> From: Eli Cohen <eli@dev.mellanox.co.il>
> Date: Wed, 26 May 2010 12:08:52 +0300
>
> > So if I understand you correctly, you think that I should not bother
> > to set a default value of 1. Each driver that cares about the value
> > of this field, will set it however they want.
>
> I actually mean that the value "0" should mean the first port,
> the value "1" should mean the second port, etc.
There's a compatibility problem here though: when user-space looks at
this number it can't tell whether "0" really means the first port or
that the driver isn't setting dev_id. In order to tell that it would
have to check the driver or kernel version too, and this is really nasty
(what if the driver was backported?). So I think that 1-based numbering
for drivers that previously didn't set dev_id.
Why does this matter? I'm maintaining the firmware update program for
Solarflare NICs under Linux. Some of the firmware it updates is
per-port and some of it is per-board. It needs to be able to tell which
net and PCI devices are associated with the same board. At the moment
it works on the basis of PCI addresses, but this is unreliable in the
presence of virtualisation. It would be better to use board serial
number and the port identifier that I just changed the driver to use,
but since there are existing driver versions always leave dev_id = 0, I
it needs to be able to tell whether dev_id is meaningful.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <1275496088.2725.202.camel@edumazet-laptop>
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> Your patch has nothing to do with dropped packets because of rp_filter.
>
> You inserted a counter increment in a path that is not taken at all by
> packet delivery.
>
> Maybe I missed something really obvious with your patch ?
rp_filter rejects a route and packets are dropped then.
> Have you considered CONFIG_NET_DROP_MONITOR ?
> This one catches all possible cases, a developper doesnt have to patch
> his kernel to add SNMP counters everywhere...
Just looking at it. Great. A hook into skb_free. That will do.
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 16:33 UTC (permalink / raw)
To: Christoph Lameter; +Cc: David Miller, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021126500.30182@router.home>
Le mercredi 02 juin 2010 à 11:27 -0500, Christoph Lameter a écrit :
> On Wed, 2 Jun 2010, David Miller wrote:
>
> > From: Christoph Lameter <cl@linux-foundation.org>
> > Date: Wed, 2 Jun 2010 11:12:14 -0500 (CDT)
> >
> > > Its important to know why drops occur (any drops for that matter, drops
> > > mean retransmit which means latency).
> >
> > We know, that's why there is a networking tracepoint that allows you
> > to see where all drops occur. :-)
>
> Where can I find out more about the network tracepoint?
>
take a look at
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#dropwatch
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 16:28 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <alpine.DEB.2.00.1006021103410.30182@router.home>
Le mercredi 02 juin 2010 à 11:12 -0500, Christoph Lameter a écrit :
> On Wed, 2 Jun 2010, Eric Dumazet wrote:
>
> > Le mercredi 02 juin 2010 à 10:27 -0500, Christoph Lameter a écrit :
> >
> > > Yes but they are not increment any counter. If packets are dropped because
> > > of the rp_filter setting interfering f.e. then the packets vanish without
> > > any accounting.
> > >
> >
> > But packets are vanishing either way.
>
> Its important to know why drops occur (any drops for that matter, drops
> mean retransmit which means latency). The symptom here was that
> multicast traffic on secondary interfaces was not being forwarded to the application.
> The rp_filter just dropped them and there was no way to easily track down
> the issue for the people experiencing the problem.
>
I just dont follow you.
Your patch has nothing to do with dropped packets because of rp_filter.
You inserted a counter increment in a path that is not taken at all by
packet delivery.
Maybe I missed something really obvious with your patch ?
It should only matters for the admin doing following command :
ip route get 1.2.3.4 from 192.168.0.1 iif eth0
That is a probe, not a 'packet delivery', this is why I said
incrementing an official MIB counter was probably wrong.
> In 2.6.31 the rp_filter was fixed to work properly with multicast and now
> it considers multicast traffic to secondary interfaces to have the wrong
> reverse path even though the multicast subscription occurred on the
> secondary interface. So it drops multicast traffic. The rp_filter has to
> be switched off when using multiple NICs for multicast load balancing.
>
Have you considered CONFIG_NET_DROP_MONITOR ?
This one catches all possible cases, a developper doesnt have to patch
his kernel to add SNMP counters everywhere...
config NET_DROP_MONITOR
boolean "Network packet drop alerting service"
depends on INET && EXPERIMENTAL && TRACEPOINTS
---help---
This feature provides an alerting service to userspace in the
event that packets are discarded in the network stack. Alerts
are broadcast via netlink socket to any listening user space
process. If you don't need network drop alerts, or if you are ok
just checking the various proc files and other utilities for
drop statistics, say N here.
> > > LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
> > > counters that allow us to diagnose and distinguish all the different
> > > causes of packet loss? We would love to have that.
> > >
> >
> > For an example, you could take a look at commit 907cdda5205b
> > (tcp: Add SNMP counter for DEFER_ACCEPT)
>
> Well these are all TCP counters. I would add IP and UDP counters?
Why not ?
But as David said, it should be motivated by real use case ;)
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:27 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <20100602.091909.113727983.davem@davemloft.net>
On Wed, 2 Jun 2010, David Miller wrote:
> From: Christoph Lameter <cl@linux-foundation.org>
> Date: Wed, 2 Jun 2010 11:12:14 -0500 (CDT)
>
> > Its important to know why drops occur (any drops for that matter, drops
> > mean retransmit which means latency).
>
> We know, that's why there is a networking tracepoint that allows you
> to see where all drops occur. :-)
Where can I find out more about the network tracepoint?
^ permalink raw reply
* RE: [PATCH net-next-2.6] net: replace hooks in __netif_receive_skb V5
From: Fischer, Anna @ 2010-06-02 16:20 UTC (permalink / raw)
To: Jiri Pirko, netdev@vger.kernel.org
Cc: davem@davemloft.net, kaber@trash.net, eric.dumazet@gmail.com,
shemminger@vyatta.com
In-Reply-To: <20100602075207.GD2603@psychotron.redhat.com>
> Subject: [PATCH net-next-2.6] net: replace hooks in __netif_receive_skb
> V5
>
> What this patch does is it removes two receive frame hooks (for bridge
> and for
> macvlan) from __netif_receive_skb. These are replaced them with a single
> hook for both. It only supports one hook per device because it makes no
> sense to do bridging and macvlan on the same device.
>
> Then a network driver (of virtual netdev like macvlan or bridge) can
> register
> an rx_handler for needed net device.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
I would like to see this being accepted. As mentioned before I would love to be able to support multiple receive frame hooks per device, but I think this is a good start.
I think especially with virtualization coming into Linux and new network virtualization approaches being developed it would be nice to have a more generic function for packet receive handlers to hook into the network stack more cleanly. Current approaches rely on 'misusing' the bridging hook into the kernel, because the packet 'sniffing' hooks (via dev_pack_add()) do not give enough control over packet processing.
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 16:21 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev
In-Reply-To: <m1ljaxxvcj.fsf@fess.ebiederm.org>
On Wed, 2010-06-02 at 09:17 -0700, Eric W. Biederman wrote:
> >> Ah, so the network devices aren't getting removed?
> >
> > Well the netdevs are gone, just the links aren't going away. the
> > mac80211_hwsim directory is gone too.
> >
> >> Do you have network namespaces enabled in your kernel or disabled?
> >
> > enabled
> >
> >> And this is 2.6.35-rc1, right?
> >
> > yes.
> >
> > Come to think of it, maybe somehow it ends up removing
> > mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
> > guess I could make it print messages about that somehow?
>
> The wireless drivers are a little different, and come to think of it
> network namespace support has been added to the wireless drivers since
> last I looked closely.
Yeah, I now need to go add tagged sysfs support to it too.
> Do you know what creates/deletes these links?
> Is it the normal register_netdevice -> device_add path?
Yes, they aren't done specially.
> I definitely changed the symlink code a little making things network namespace
> aware so it is reasonable to assume that something in my changes affected the
> wireless drivers.
> I took a quick look and with my patches against 2.6.33 I'm not seeing this.
Hmm. I'm also not seeing it with veth, it would seem that ought to be
similar?
> I take a closer look at 2.6.35-rc1 and see if I can figure out what is
> going on. It would definitely be wrong if hwsim0 is removed before
> wlan0.
I don't know if that's happening .. just guessing that it might cause
such a problem, and maybe some things are deferred somehow? Since netdev
destruction can be deferred, but the wifi sysfs destruction isn't. But
then that link there should cause the refcount to not go down until the
link goes away>?
johannes
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: David Miller @ 2010-06-02 16:19 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <alpine.DEB.2.00.1006021103410.30182@router.home>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 2 Jun 2010 11:12:14 -0500 (CDT)
> Its important to know why drops occur (any drops for that matter, drops
> mean retransmit which means latency).
We know, that's why there is a networking tracepoint that allows you
to see where all drops occur. :-)
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Eric W. Biederman @ 2010-06-02 16:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg KH, netdev
In-Reply-To: <1275493693.3915.12.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-06-02 at 08:46 -0700, Greg KH wrote:
>
>> > # rmmod mac80211_hwsim mac80211 cfg80211
>> > # ip link
>> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
>> > link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
>> > # ls -l /sys/class/net/
>> > total 0
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
>> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
>>
>> Ah, so the network devices aren't getting removed?
>
> Well the netdevs are gone, just the links aren't going away. the
> mac80211_hwsim directory is gone too.
>
>> Do you have network namespaces enabled in your kernel or disabled?
>
> enabled
>
>> And this is 2.6.35-rc1, right?
>
> yes.
>
> Come to think of it, maybe somehow it ends up removing
> mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
> guess I could make it print messages about that somehow?
The wireless drivers are a little different, and come to think of it
network namespace support has been added to the wireless drivers since
last I looked closely. Do you know what creates/deletes these links?
Is it the normal register_netdevice -> device_add path?
I definitely changed the symlink code a little making things network namespace
aware so it is reasonable to assume that something in my changes affected the
wireless drivers.
I took a quick look and with my patches against 2.6.33 I'm not seeing this.
I take a closer look at 2.6.35-rc1 and see if I can figure out what is
going on. It would definitely be wrong if hwsim0 is removed before
wlan0. Still on my todo it seems is to fix the lifetime issues of all
of the callers, grr.
Eric
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Christoph Lameter @ 2010-06-02 16:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger, David Miller
In-Reply-To: <1275492754.2725.192.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1455 bytes --]
On Wed, 2 Jun 2010, Eric Dumazet wrote:
> Le mercredi 02 juin 2010 à 10:27 -0500, Christoph Lameter a écrit :
>
> > Yes but they are not increment any counter. If packets are dropped because
> > of the rp_filter setting interfering f.e. then the packets vanish without
> > any accounting.
> >
>
> But packets are vanishing either way.
Its important to know why drops occur (any drops for that matter, drops
mean retransmit which means latency). The symptom here was that
multicast traffic on secondary interfaces was not being forwarded to the application.
The rp_filter just dropped them and there was no way to easily track down
the issue for the people experiencing the problem.
In 2.6.31 the rp_filter was fixed to work properly with multicast and now
it considers multicast traffic to secondary interfaces to have the wrong
reverse path even though the multicast subscription occurred on the
secondary interface. So it drops multicast traffic. The rp_filter has to
be switched off when using multiple NICs for multicast load balancing.
> > LINUX_MIB_INROUTEERRORS? Does it mean I can create a series of new
> > counters that allow us to diagnose and distinguish all the different
> > causes of packet loss? We would love to have that.
> >
>
> For an example, you could take a look at commit 907cdda5205b
> (tcp: Add SNMP counter for DEFER_ACCEPT)
Well these are all TCP counters. I would add IP and UDP counters?
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-28
From: reinette chatre @ 2010-06-02 16:01 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: John W. Linville, davem@davemloft.net,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Zheng, Jiajia, Kolekar, Abhijeet,
Berg, Johannes
In-Reply-To: <AANLkTimo_CpVC0B99GMJtIllAye5Yqa5yiIAiFBY-pIN@mail.gmail.com>
On Wed, 2010-06-02 at 01:42 -0700, Sedat Dilek wrote:
> What do you mean by "upstream"?
> upstream for me is Linus-tree (linux-2.6 GIT master).
> Patches against iwlwifi-2.6 GIT trees are not very helpful in my case.
Since the problem exists in 2.6.35-rc1 linux-2.6 is indeed the target
for this fix.
Reinette
^ permalink raw reply
* Re: [PATCH] ppp_generic: fix multilink fragment sizes
From: Ben McKeegan @ 2010-06-02 15:55 UTC (permalink / raw)
To: Paoloni, Gabriele
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, alan@lxorguk.ukuu.org.uk,
linux-ppp@vger.kernel.org, paulus@samba.org
In-Reply-To: <DF7BB929B28FCF479E888E3D9F8D9E88D3E16B5A@irsmsx502.ger.corp.intel.com>
Paoloni, Gabriele wrote:
> The proposed patch looks wrong to me.
>
> nbigger is already doing the job; I didn't use DIV_ROUND_UP because in general we don't have always to roundup, otherwise we would exceed the total bandwidth.
I was basing this on the original code prior to your patch, which used
DIV_ROUND_UP to get the fragment size. Looking more closely I see your
point, the original code was starting with the larger fragment size and
decrementing rather than starting with the smaller size and incrementing
as your code does, so that makes sense.
>
> flen = len;
> if (nfree > 0) {
> if (pch->speed == 0) {
> - flen = totlen/nfree;
> + if (nfree > 1)
> + flen = DIV_ROUND_UP(len, nfree);
> if (nbigger > 0) {
> flen++;
> nbigger--;
The important change here is the use of 'len' instead of 'totlen'.
'nfree' and 'len' should decrease roughly proportionally with each
iteration of the loop whereas 'totlen' remains unchanged. Thus
(totlen/nfree) gets bigger on each iteration whereas len/nfree should
give roughly the same. However, without rounding up here I'm not sure
the logic is right either, since the side effect of nbigger is to make
len decrease faster so it is not quite proportional to the decrease in
nfree. Is there a risk of ending up on the nfree == 1 iteration with
flen == len - 1 and thus generating a superfluous extra 1 byte long
fragment? This would be a far worse situation than a slight imbalance
in the size of the fragments.
Perhaps the solution is to go back to a precalculated fragment size for
the pch->speed == 0 case as per original code?
Regards,
Ben.
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 15:48 UTC (permalink / raw)
To: Greg KH; +Cc: netdev, Eric W. Biederman
In-Reply-To: <20100602154608.GB12361@kroah.com>
On Wed, 2010-06-02 at 08:46 -0700, Greg KH wrote:
> > # rmmod mac80211_hwsim mac80211 cfg80211
> > # ip link
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> > link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> > # ls -l /sys/class/net/
> > total 0
> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> > lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
> > lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
>
> Ah, so the network devices aren't getting removed?
Well the netdevs are gone, just the links aren't going away. the
mac80211_hwsim directory is gone too.
> Do you have network namespaces enabled in your kernel or disabled?
enabled
> And this is 2.6.35-rc1, right?
yes.
Come to think of it, maybe somehow it ends up removing
mac80211_hwsim/hwsim0 before wlan0, and thus the link stays around? I
guess I could make it print messages about that somehow?
johannes
^ permalink raw reply
* Re: sysfs class/net/ problem
From: Greg KH @ 2010-06-02 15:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Eric W. Biederman
In-Reply-To: <1275484611.3915.11.camel@jlt3.sipsolutions.net>
On Wed, Jun 02, 2010 at 03:16:51PM +0200, Johannes Berg wrote:
> Hi,
>
> I didn't find anything related in the archives, if I missed it I'd
> appreciate a pointer. I'm currently experiencing the following:
>
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> # ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> # insmod cfg80211.ko ; insmod mac80211.ko ; insmod mac80211_hwsim.ko radios=3
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> 5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 6: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
> 7: wlan2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 02:00:00:00:02:00 brd ff:ff:ff:ff:ff:ff
> 8: hwsim0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> link/ieee802.11/radiotap 12:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> # ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 hwsim0 -> ../../devices/virtual/net/hwsim0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
> # rmmod mac80211_hwsim mac80211 cfg80211
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
> # ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 eth0 -> ../../devices/pci0000:00/0000:00:03.0/net/eth0
> lrwxrwxrwx 1 root root 0 Jun 2 13:12 lo -> ../../devices/virtual/net/lo
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan0 -> ../../devices/virtual/mac80211_hwsim/hwsim0/wlan0
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan1 -> ../../devices/virtual/mac80211_hwsim/hwsim1/wlan1
> lrwxrwxrwx 1 root root 0 Jun 2 13:14 wlan2 -> ../../devices/virtual/mac80211_hwsim/hwsim2/wlan2
Ah, so the network devices aren't getting removed?
Do you have network namespaces enabled in your kernel or disabled?
And this is 2.6.35-rc1, right?
Eric, any ideas?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] mac8390: raise error logging priority
From: Finn Thain @ 2010-06-02 15:36 UTC (permalink / raw)
To: David Miller; +Cc: geert, joe, p_gortmaker, netdev, linux-kernel, linux-m68k
In-Reply-To: <20100602.070647.106817718.davem@davemloft.net>
On Wed, 2 Jun 2010, David Miller wrote:
>
> Applied, thank you.
>
You're welcome.
And I ought to add, thanks, Joe, for your patches.
It is much harder than I had realised to do them right (or for that
matter, well enough).
Finn
^ 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