* Re: sysfs class/net/ problem
From: Johannes Berg @ 2010-06-02 17:52 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev
In-Reply-To: <m1ocftwdp7.fsf@fess.ebiederm.org>
On Wed, 2010-06-02 at 10:23 -0700, Eric W. Biederman wrote:
> So far that hypothesis that the target of the symlink is being removed before
> the actual actual link looks like it could cause this.
Yeah though I'm not sure how that would happen? Wouldn't the symlink
cause the target kobject to still be referenced, and thus stay around
until the symlink goes away?
> Are there any other left overs in sysfs, besides just /sys/class/net/wlan0?
No, not based on find /sys and diffing before/after anyway.
johannes
^ permalink raw reply
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Eric Dumazet @ 2010-06-02 17:46 UTC (permalink / raw)
To: David Miller; +Cc: cl, netdev, shemminger
In-Reply-To: <20100602.103102.121237521.davem@davemloft.net>
Le mercredi 02 juin 2010 à 10:31 -0700, David Miller a écrit :
> 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.
Thanks !
Here is the patch I cooked to account for RP_FILTER errors in multicast
path.
I will complete it to also do the unicast part before official
submission.
Christoph, the official counter would be IPSTATS_MIB_INNOROUTES
ipSystemStatsInNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of input IP datagrams discarded because no route
could be found to transmit them to their destination.
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 4f0ed45..f207289 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -284,7 +284,7 @@ int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
if (no_addr)
goto last_resort;
if (rpf == 1)
- goto e_inval;
+ goto e_rpf;
fl.oif = dev->ifindex;
ret = 0;
@@ -299,7 +299,7 @@ int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
last_resort:
if (rpf)
- goto e_inval;
+ goto e_rpf;
*spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
*itag = 0;
return 0;
@@ -308,6 +308,8 @@ e_inval_res:
fib_res_put(&res);
e_inval:
return -EINVAL;
+e_rpf:
+ return -ENETUNREACH;
}
static inline __be32 sk_extract_addr(struct sockaddr *addr)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 8495bce..8e9e2f9 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1851,6 +1851,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
__be32 spec_dst;
struct in_device *in_dev = in_dev_get(dev);
u32 itag = 0;
+ int err;
/* Primary sanity checks. */
@@ -1865,10 +1866,12 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (!ipv4_is_local_multicast(daddr))
goto e_inval;
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_LINK);
- } else if (fib_validate_source(saddr, 0, tos, 0,
- dev, &spec_dst, &itag, 0) < 0)
- goto e_inval;
-
+ } else {
+ err = fib_validate_source(saddr, 0, tos, 0, dev, &spec_dst,
+ &itag, 0);
+ if (err < 0)
+ goto e_err;
+ }
rth = dst_alloc(&ipv4_dst_ops);
if (!rth)
goto e_nobufs;
@@ -1922,6 +1925,9 @@ e_nobufs:
e_inval:
in_dev_put(in_dev);
return -EINVAL;
+e_err:
+ in_dev_put(in_dev);
+ return err;
}
^ permalink raw reply related
* [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts
From: Geert Uytterhoeven @ 2010-06-02 17:36 UTC (permalink / raw)
To: davem; +Cc: netdev, Geert Uytterhoeven
commit 5c7fffd0e3b57cb63f50bbd710868f012d67654f ("drivers/net/mac8390.c: Remove
useless memcpy casting") removed too many casts, introducing the following
warnings:
| drivers/net/mac8390.c:248: warning: passing argument 1 of '__builtin_memcpy' makes pointer from integer without a cast
| drivers/net/mac8390.c:253: warning: passing argument 1 of 'word_memcpy_tocard' makes pointer from integer without a cast
| drivers/net/mac8390.c:255: warning: passing argument 2 of 'word_memcpy_fromcard' makes pointer from integer without a cast
Instead of just readding the casts,
- move all casts inside word_memcpy_{to,from}card(),
- replace an incorrect memcpy() by memcpy_toio(),
- add memcmp_withio() as a wrapper around memcmp(),
- replace an incorrect memcpy_toio() by memcpy_fromio().
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Finn Thain <fthain@telegraphics.com.au>
---
drivers/net/mac8390.c | 44 ++++++++++++++++++++++----------------------
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/net/mac8390.c b/drivers/net/mac8390.c
index 1136c9a..c7476a4 100644
--- a/drivers/net/mac8390.c
+++ b/drivers/net/mac8390.c
@@ -157,6 +157,8 @@ static void dayna_block_output(struct net_device *dev, int count,
#define memcpy_fromio(a, b, c) memcpy((a), (void *)(b), (c))
#define memcpy_toio(a, b, c) memcpy((void *)(a), (b), (c))
+#define memcmp_withio(a, b, c) memcmp((a), (void *)(b), (c))
+
/* Slow Sane (16-bit chunk memory read/write) Cabletron uses this */
static void slow_sane_get_8390_hdr(struct net_device *dev,
struct e8390_pkt_hdr *hdr, int ring_page);
@@ -164,8 +166,8 @@ static void slow_sane_block_input(struct net_device *dev, int count,
struct sk_buff *skb, int ring_offset);
static void slow_sane_block_output(struct net_device *dev, int count,
const unsigned char *buf, int start_page);
-static void word_memcpy_tocard(void *tp, const void *fp, int count);
-static void word_memcpy_fromcard(void *tp, const void *fp, int count);
+static void word_memcpy_tocard(unsigned long tp, const void *fp, int count);
+static void word_memcpy_fromcard(void *tp, unsigned long fp, int count);
static enum mac8390_type __init mac8390_ident(struct nubus_dev *dev)
{
@@ -245,9 +247,9 @@ static enum mac8390_access __init mac8390_testio(volatile unsigned long membase)
unsigned long outdata = 0xA5A0B5B0;
unsigned long indata = 0x00000000;
/* Try writing 32 bits */
- memcpy(membase, &outdata, 4);
+ memcpy_toio(membase, &outdata, 4);
/* Now compare them */
- if (memcmp((char *)&outdata, (char *)membase, 4) == 0)
+ if (memcmp_withio(&outdata, membase, 4) == 0)
return ACCESS_32;
/* Write 16 bit output */
word_memcpy_tocard(membase, &outdata, 4);
@@ -731,7 +733,7 @@ static void sane_get_8390_hdr(struct net_device *dev,
struct e8390_pkt_hdr *hdr, int ring_page)
{
unsigned long hdr_start = (ring_page - WD_START_PG)<<8;
- memcpy_fromio((void *)hdr, (char *)dev->mem_start + hdr_start, 4);
+ memcpy_fromio(hdr, dev->mem_start + hdr_start, 4);
/* Fix endianness */
hdr->count = swab16(hdr->count);
}
@@ -745,14 +747,13 @@ static void sane_block_input(struct net_device *dev, int count,
if (xfer_start + count > ei_status.rmem_end) {
/* We must wrap the input move. */
int semi_count = ei_status.rmem_end - xfer_start;
- memcpy_fromio(skb->data, (char *)dev->mem_start + xfer_base,
+ memcpy_fromio(skb->data, dev->mem_start + xfer_base,
semi_count);
count -= semi_count;
- memcpy_toio(skb->data + semi_count,
- (char *)ei_status.rmem_start, count);
- } else {
- memcpy_fromio(skb->data, (char *)dev->mem_start + xfer_base,
+ memcpy_fromio(skb->data + semi_count, ei_status.rmem_start,
count);
+ } else {
+ memcpy_fromio(skb->data, dev->mem_start + xfer_base, count);
}
}
@@ -761,7 +762,7 @@ static void sane_block_output(struct net_device *dev, int count,
{
long shmem = (start_page - WD_START_PG)<<8;
- memcpy_toio((char *)dev->mem_start + shmem, buf, count);
+ memcpy_toio(dev->mem_start + shmem, buf, count);
}
/* dayna block input/output */
@@ -812,7 +813,7 @@ static void slow_sane_get_8390_hdr(struct net_device *dev,
int ring_page)
{
unsigned long hdr_start = (ring_page - WD_START_PG)<<8;
- word_memcpy_fromcard(hdr, (char *)dev->mem_start + hdr_start, 4);
+ word_memcpy_fromcard(hdr, dev->mem_start + hdr_start, 4);
/* Register endianism - fix here rather than 8390.c */
hdr->count = (hdr->count&0xFF)<<8|(hdr->count>>8);
}
@@ -826,15 +827,14 @@ static void slow_sane_block_input(struct net_device *dev, int count,
if (xfer_start + count > ei_status.rmem_end) {
/* We must wrap the input move. */
int semi_count = ei_status.rmem_end - xfer_start;
- word_memcpy_fromcard(skb->data,
- (char *)dev->mem_start + xfer_base,
+ word_memcpy_fromcard(skb->data, dev->mem_start + xfer_base,
semi_count);
count -= semi_count;
word_memcpy_fromcard(skb->data + semi_count,
- (char *)ei_status.rmem_start, count);
+ ei_status.rmem_start, count);
} else {
- word_memcpy_fromcard(skb->data,
- (char *)dev->mem_start + xfer_base, count);
+ word_memcpy_fromcard(skb->data, dev->mem_start + xfer_base,
+ count);
}
}
@@ -843,12 +843,12 @@ static void slow_sane_block_output(struct net_device *dev, int count,
{
long shmem = (start_page - WD_START_PG)<<8;
- word_memcpy_tocard((char *)dev->mem_start + shmem, buf, count);
+ word_memcpy_tocard(dev->mem_start + shmem, buf, count);
}
-static void word_memcpy_tocard(void *tp, const void *fp, int count)
+static void word_memcpy_tocard(unsigned long tp, const void *fp, int count)
{
- volatile unsigned short *to = tp;
+ volatile unsigned short *to = (void *)tp;
const unsigned short *from = fp;
count++;
@@ -858,10 +858,10 @@ static void word_memcpy_tocard(void *tp, const void *fp, int count)
*to++ = *from++;
}
-static void word_memcpy_fromcard(void *tp, const void *fp, int count)
+static void word_memcpy_fromcard(void *tp, unsigned long fp, int count)
{
unsigned short *to = tp;
- const volatile unsigned short *from = fp;
+ const volatile unsigned short *from = (const void *)fp;
count++;
count /= 2;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] IP: Increment INADDRERRORS if routing for a packet is not successful
From: Neil Horman @ 2010-06-02 17:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, cl, netdev, shemminger
In-Reply-To: <1275499150.2519.0.camel@edumazet-laptop>
On Wed, Jun 02, 2010 at 07:19:10PM +0200, Eric Dumazet wrote:
> 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 ;)
>
That stap script was really meant to be a stopgap measure. As mentioned, you
can use the debugfs interface to turn tracepoints on and use them anyway you
wish. Or, if you want to use the kfree_skb and napi_poll tracepoints in a more
formalized way, you can use the dropwatch user space utility:
https://fedorahosted.org/dropwatch/
Which includes a man page on usage :)
I also recently updated it so that this utility can query /proc/kallsyms to
translate program counter values into symbollic names and offsets for you. :)
Regards
Neil
^ permalink raw reply
* 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
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