* Re: [PATCH] [IPv4] Reply net unreachable ICMP message
From: Jarek Poplawski @ 2007-12-06 8:47 UTC (permalink / raw)
To: Mitsuru Chinen; +Cc: netdev, David Miller, Rami Rosen
In-Reply-To: <20071206171421.1495c019.mitch@linux.vnet.ibm.com>
On 06-12-2007 09:14, Mitsuru Chinen wrote:
> On Thu, 6 Dec 2007 08:49:47 +0100
> Jarek Poplawski <jarkao2@o2.pl> wrote:
>
>> On 06-12-2007 07:31, Mitsuru Chinen wrote:
>>> IPv4 stack doesn't reply any ICMP destination unreachable message
>>> with net unreachable code when IP detagrams are being discarded
>>> because of no route could be found in the forwarding path.
>>> Incidentally, IPv6 stack replies such ICMPv6 message in the similar
>>> situation.
...
>> This patch seems to be wrong. It overrides err codes from
>> fib_lookup, where such decisions should be made.
>
> fib_lookup() replies -ESRCH in this situation.
> It is necessary to override the variable by the suitable error
> number like the code under e_hostunreach label.
Probably I miss something, but I can't see how can you be sure it's
only -ESRCH possible here? Isn't opt->action() in fib_rules_lookup()
supposed to return this -ENETUNREACH when needed?
Jarek P.
^ permalink raw reply
* Re: [PATCH] [IPv4] Reply net unreachable ICMP message
From: Mitsuru Chinen @ 2007-12-06 8:14 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Jarek Poplawski, netdev, David Miller
In-Reply-To: <20071206074946.GA2164@ff.dom.local>
On Thu, 6 Dec 2007 08:49:47 +0100
Jarek Poplawski <jarkao2@o2.pl> wrote:
> On 06-12-2007 07:31, Mitsuru Chinen wrote:
> > IPv4 stack doesn't reply any ICMP destination unreachable message
> > with net unreachable code when IP detagrams are being discarded
> > because of no route could be found in the forwarding path.
> > Incidentally, IPv6 stack replies such ICMPv6 message in the similar
> > situation.
> >
> > Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
> > ---
> > net/ipv4/route.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index 6714bbc..ba85ec9 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -1375,6 +1375,7 @@ static int ip_error(struct sk_buff *skb)
> > break;
> > case ENETUNREACH:
> > code = ICMP_NET_UNREACH;
> > + IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
> > break;
> > case EACCES:
> > code = ICMP_PKT_FILTERED;
> > @@ -2004,6 +2005,7 @@ no_route:
> > RT_CACHE_STAT_INC(in_no_route);
> > spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
> > res.type = RTN_UNREACHABLE;
> > + err = -ENETUNREACH;
> > goto local_input;
> >
> > /*
>
> This patch seems to be wrong. It overrides err codes from
> fib_lookup, where such decisions should be made.
fib_lookup() replies -ESRCH in this situation.
It is necessary to override the variable by the suitable error
number like the code under e_hostunreach label.
Best Regards,
----
Mitsuru Chinen <mitch@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH] [IPv4] Reply net unreachable ICMP message
From: Rami Rosen @ 2007-12-06 8:12 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Mitsuru Chinen, netdev, David Miller
In-Reply-To: <20071206074946.GA2164@ff.dom.local>
Hello, Jarek,
I am sorry, but I think I am nor sure I underatand exactly what you mean when
you say:
"It overrides err codes from fib_lookup, where such decisions should be made."
What is incorrect here ?
There are two lines added in this patch;
IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
and err = -ENETUNREACH;
The first one is, regardless to say, not relevant to err codes.
The second, err = -ENETUNREACH, is from: ip_route_input_slow().
(net/ipv4/route.c).
Assigning values to err is done more than once in this method;
for example,
e_hostunreach:
err = -EHOSTUNREACH;
e_inval:
err = -EINVAL;
e_nobufs:
err = -ENOBUFS;
So I don't think anything is incorrect here.
Regards,
Rami Rosen
On Dec 6, 2007 9:49 AM, Jarek Poplawski <jarkao2@o2.pl> wrote:
>
> On 06-12-2007 07:31, Mitsuru Chinen wrote:
> > IPv4 stack doesn't reply any ICMP destination unreachable message
> > with net unreachable code when IP detagrams are being discarded
> > because of no route could be found in the forwarding path.
> > Incidentally, IPv6 stack replies such ICMPv6 message in the similar
> > situation.
> >
> > Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
> > ---
> > net/ipv4/route.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index 6714bbc..ba85ec9 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -1375,6 +1375,7 @@ static int ip_error(struct sk_buff *skb)
> > break;
> > case ENETUNREACH:
> > code = ICMP_NET_UNREACH;
> > + IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
> > break;
> > case EACCES:
> > code = ICMP_PKT_FILTERED;
> > @@ -2004,6 +2005,7 @@ no_route:
> > RT_CACHE_STAT_INC(in_no_route);
> > spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
> > res.type = RTN_UNREACHABLE;
> > + err = -ENETUNREACH;
> > goto local_input;
> >
> > /*
>
> This patch seems to be wrong. It overrides err codes from
> fib_lookup, where such decisions should be made.
>
> Regards,
> Jarek P.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] [IPv4] Reply net unreachable ICMP message
From: Jarek Poplawski @ 2007-12-06 7:49 UTC (permalink / raw)
To: Mitsuru Chinen; +Cc: netdev, David Miller
In-Reply-To: <20071206153105.df7d112f.mitch@linux.vnet.ibm.com>
On 06-12-2007 07:31, Mitsuru Chinen wrote:
> IPv4 stack doesn't reply any ICMP destination unreachable message
> with net unreachable code when IP detagrams are being discarded
> because of no route could be found in the forwarding path.
> Incidentally, IPv6 stack replies such ICMPv6 message in the similar
> situation.
>
> Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
> ---
> net/ipv4/route.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 6714bbc..ba85ec9 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1375,6 +1375,7 @@ static int ip_error(struct sk_buff *skb)
> break;
> case ENETUNREACH:
> code = ICMP_NET_UNREACH;
> + IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
> break;
> case EACCES:
> code = ICMP_PKT_FILTERED;
> @@ -2004,6 +2005,7 @@ no_route:
> RT_CACHE_STAT_INC(in_no_route);
> spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
> res.type = RTN_UNREACHABLE;
> + err = -ENETUNREACH;
> goto local_input;
>
> /*
This patch seems to be wrong. It overrides err codes from
fib_lookup, where such decisions should be made.
Regards,
Jarek P.
^ permalink raw reply
* Re: 2.6.24-rc4-mm1
From: Andrew Morton @ 2007-12-06 7:35 UTC (permalink / raw)
To: Reuben Farrelly
Cc: linux-kernel, Linux Netdev List, Auke Kok, Ilpo Järvinen
In-Reply-To: <47579DD9.9030909@reub.net>
On Thu, 06 Dec 2007 17:59:37 +1100 Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
> On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
> >
> > Will appear later at
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
> >
> >
> > - Lots of device IDs have been removed from the e1000 driver and moved over
> > to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
>
> This non fatal oops which I have just noticed may be related to this change then
> - certainly looks networking related.
yep, but it isn't e1000. It's core TCP.
> WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
> Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
>
> Call Trace:
> <IRQ> [<ffffffff8046e038>] tcp_fastretrans_alert+0x229/0xe63
> [<ffffffff80470975>] tcp_ack+0xa3f/0x127d
> [<ffffffff804747b7>] tcp_rcv_established+0x55f/0x7f8
> [<ffffffff8047b1aa>] tcp_v4_do_rcv+0xdb/0x3a7
> [<ffffffff881148a8>] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
> [<ffffffff88120179>] :nf_conntrack_ipv4:ipv4_confirm+0x29/0x51
> [<ffffffff8047db71>] tcp_v4_rcv+0x9be/0xaed
> [<ffffffff80455eaa>] nf_hook_slow+0x60/0xdf
> [<ffffffff8045db6b>] ip_local_deliver_finish+0xd3/0x253
> [<ffffffff8045e146>] ip_local_deliver+0x3b/0x85
> [<ffffffff8045d7f9>] ip_rcv_finish+0x119/0x3b8
> [<ffffffff8045e030>] ip_rcv+0x231/0x30c
> [<ffffffff8043ef39>] netif_receive_skb+0x215/0x299
> [<ffffffff880b82b9>] :e1000e:e1000_receive_skb+0x4d/0x1db
> [<ffffffff880bc200>] :e1000e:e1000_clean_rx_irq+0x12c/0x341
> [<ffffffff880ba31a>] :e1000e:e1000_clean+0x306/0x58f
> [<ffffffff8022a16a>] rebalance_domains+0xec/0x423
> [<ffffffff80261332>] handle_edge_irq+0x97/0x13b
> [<ffffffff804412d3>] net_rx_action+0xb8/0x11d
> [<ffffffff802344f8>] __do_softirq+0x71/0xdd
> [<ffffffff8020c8fc>] call_softirq+0x1c/0x30
> [<ffffffff8020e7a5>] do_softirq+0x3d/0x8d
> [<ffffffff80234485>] irq_exit+0x84/0x86
> [<ffffffff8020e89e>] do_IRQ+0x7e/0xe4
> [<ffffffff8020a908>] mwait_idle+0x0/0x58
> [<ffffffff8020a7f1>] default_idle+0x0/0x43
> [<ffffffff8020bc81>] ret_from_intr+0x0/0xa
> <EOI> [<ffffffff8020a950>] mwait_idle+0x48/0x58
> [<ffffffff80209f23>] enter_idle+0x22/0x24
> [<ffffffff8020a897>] cpu_idle+0x63/0x88
> [<ffffffff804ada75>] rest_init+0x55/0x60
> [<ffffffff80627b9a>] start_kernel+0x2a4/0x32a
> [<ffffffff8062710b>] _sinittext+0x10b/0x120
>
> tornado home #
>
> I have posted a full dmesg up as well as my .config and an lcpci at
> http://www.reub.net/files/kernel/2.6.24-rc4-mm1/ .
>
Ilpo, Reuben's kernel is talking to you ;)
^ permalink raw reply
* Re: 2.6.24-rc4-mm1
From: David Miller @ 2007-12-06 7:09 UTC (permalink / raw)
To: reuben-linuxkernel
Cc: akpm, linux-kernel, netdev, auke-jan.h.kok, ilpo.jarvinen
In-Reply-To: <47579DD9.9030909@reub.net>
From: Reuben Farrelly <reuben-linuxkernel@reub.net>
Date: Thu, 06 Dec 2007 17:59:37 +1100
> On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > - Lots of device IDs have been removed from the e1000 driver and moved over
> > to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
>
> This non fatal oops which I have just noticed may be related to this change then
> - certainly looks networking related.
>
> WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
> Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
>
> Call Trace:
> <IRQ> [<ffffffff8046e038>] tcp_fastretrans_alert+0x229/0xe63
> [<ffffffff80470975>] tcp_ack+0xa3f/0x127d
> [<ffffffff804747b7>] tcp_rcv_established+0x55f/0x7f8
> [<ffffffff8047b1aa>] tcp_v4_do_rcv+0xdb/0x3a7
> [<ffffffff881148a8>] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
No, it's from TCP assertions and changes added by Ilpo to the
net-2.6.25 tree recently.
^ permalink raw reply
* Re: 2.6.24-rc4-mm1
From: Reuben Farrelly @ 2007-12-06 6:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Linux Netdev List, Auke Kok
In-Reply-To: <20071204211701.994dfce6.akpm@linux-foundation.org>
On 5/12/2007 4:17 PM, Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
>
> Will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
>
>
> - Lots of device IDs have been removed from the e1000 driver and moved over
> to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
This non fatal oops which I have just noticed may be related to this change then
- certainly looks networking related.
WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
Call Trace:
<IRQ> [<ffffffff8046e038>] tcp_fastretrans_alert+0x229/0xe63
[<ffffffff80470975>] tcp_ack+0xa3f/0x127d
[<ffffffff804747b7>] tcp_rcv_established+0x55f/0x7f8
[<ffffffff8047b1aa>] tcp_v4_do_rcv+0xdb/0x3a7
[<ffffffff881148a8>] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
[<ffffffff88120179>] :nf_conntrack_ipv4:ipv4_confirm+0x29/0x51
[<ffffffff8047db71>] tcp_v4_rcv+0x9be/0xaed
[<ffffffff80455eaa>] nf_hook_slow+0x60/0xdf
[<ffffffff8045db6b>] ip_local_deliver_finish+0xd3/0x253
[<ffffffff8045e146>] ip_local_deliver+0x3b/0x85
[<ffffffff8045d7f9>] ip_rcv_finish+0x119/0x3b8
[<ffffffff8045e030>] ip_rcv+0x231/0x30c
[<ffffffff8043ef39>] netif_receive_skb+0x215/0x299
[<ffffffff880b82b9>] :e1000e:e1000_receive_skb+0x4d/0x1db
[<ffffffff880bc200>] :e1000e:e1000_clean_rx_irq+0x12c/0x341
[<ffffffff880ba31a>] :e1000e:e1000_clean+0x306/0x58f
[<ffffffff8022a16a>] rebalance_domains+0xec/0x423
[<ffffffff80261332>] handle_edge_irq+0x97/0x13b
[<ffffffff804412d3>] net_rx_action+0xb8/0x11d
[<ffffffff802344f8>] __do_softirq+0x71/0xdd
[<ffffffff8020c8fc>] call_softirq+0x1c/0x30
[<ffffffff8020e7a5>] do_softirq+0x3d/0x8d
[<ffffffff80234485>] irq_exit+0x84/0x86
[<ffffffff8020e89e>] do_IRQ+0x7e/0xe4
[<ffffffff8020a908>] mwait_idle+0x0/0x58
[<ffffffff8020a7f1>] default_idle+0x0/0x43
[<ffffffff8020bc81>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff8020a950>] mwait_idle+0x48/0x58
[<ffffffff80209f23>] enter_idle+0x22/0x24
[<ffffffff8020a897>] cpu_idle+0x63/0x88
[<ffffffff804ada75>] rest_init+0x55/0x60
[<ffffffff80627b9a>] start_kernel+0x2a4/0x32a
[<ffffffff8062710b>] _sinittext+0x10b/0x120
tornado home #
I have posted a full dmesg up as well as my .config and an lcpci at
http://www.reub.net/files/kernel/2.6.24-rc4-mm1/ .
Thanks,
Reuben
^ permalink raw reply
* Re: [PATCH] [IPv4] Reply net unreachable ICMP message
From: David Miller @ 2007-12-06 6:33 UTC (permalink / raw)
To: mitch; +Cc: netdev
In-Reply-To: <20071206153105.df7d112f.mitch@linux.vnet.ibm.com>
From: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
Date: Thu, 6 Dec 2007 15:31:05 +0900
> IPv4 stack doesn't reply any ICMP destination unreachable message
> with net unreachable code when IP detagrams are being discarded
> because of no route could be found in the forwarding path.
> Incidentally, IPv6 stack replies such ICMPv6 message in the similar
> situation.
>
> Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
Also applied, thank you.
^ permalink raw reply
* Re: [PATCH] [IPv6] SNMP: Increment OutNoRoutes when connecting to unreachable network
From: David Miller @ 2007-12-06 6:32 UTC (permalink / raw)
To: mitch; +Cc: netdev
In-Reply-To: <20071206152948.1f593cd5.mitch@linux.vnet.ibm.com>
From: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
Date: Thu, 6 Dec 2007 15:29:48 +0900
> IPv6 stack doesn't increment OutNoRoutes counter when IP datagrams
> is being discarded because no route could be found to transmit them
> to their destination. IPv6 stack should increment the counter.
> Incidentally, IPv4 stack increments that counter in such situation.
>
> Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
Patch applied, thanks!
^ permalink raw reply
* [PATCH] [IPv4] Reply net unreachable ICMP message
From: Mitsuru Chinen @ 2007-12-06 6:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller
IPv4 stack doesn't reply any ICMP destination unreachable message
with net unreachable code when IP detagrams are being discarded
because of no route could be found in the forwarding path.
Incidentally, IPv6 stack replies such ICMPv6 message in the similar
situation.
Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
---
net/ipv4/route.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 6714bbc..ba85ec9 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1375,6 +1375,7 @@ static int ip_error(struct sk_buff *skb)
break;
case ENETUNREACH:
code = ICMP_NET_UNREACH;
+ IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
break;
case EACCES:
code = ICMP_PKT_FILTERED;
@@ -2004,6 +2005,7 @@ no_route:
RT_CACHE_STAT_INC(in_no_route);
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
res.type = RTN_UNREACHABLE;
+ err = -ENETUNREACH;
goto local_input;
/*
--
1.5.3.4
^ permalink raw reply related
* [PATCH] [IPv6] SNMP: Increment OutNoRoutes when connecting to unreachable network
From: Mitsuru Chinen @ 2007-12-06 6:29 UTC (permalink / raw)
To: netdev; +Cc: David Miller
IPv6 stack doesn't increment OutNoRoutes counter when IP datagrams
is being discarded because no route could be found to transmit them
to their destination. IPv6 stack should increment the counter.
Incidentally, IPv4 stack increments that counter in such situation.
Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
---
net/ipv6/ip6_output.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 89cca7c..388a098 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -960,6 +960,8 @@ static int ip6_dst_lookup_tail(struct sock *sk,
return 0;
out_err_release:
+ if (err == -ENETUNREACH)
+ IP6_INC_STATS_BH(NULL, IPSTATS_MIB_OUTNOROUTES);
dst_release(*dst);
*dst = NULL;
return err;
--
1.5.3.4
^ permalink raw reply related
* [PATCH] fix br_fdb_fini() section mismatch
From: Harald Welte @ 2007-12-06 5:26 UTC (permalink / raw)
To: Linux Netdev List; +Cc: linux-kernel, David Miller
When compiling a kernel (current linus git or 2.6.24-rc4) with built-in
CONFIG_BRIDGE, I get the following error:
LD .tmp_vmlinux1
`br_fdb_fini' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
make: *** [.tmp_vmlinux1] Error 1
This patch fixes it.
Signed-off-by: Harald Welte <laforge@gnumonks.org>
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index eb57502..bc40377 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -44,7 +44,7 @@ int __init br_fdb_init(void)
return 0;
}
-void __exit br_fdb_fini(void)
+void br_fdb_fini(void)
{
kmem_cache_destroy(br_fdb_cache);
}
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply related
* Re: [BRIDGE] warning message when add an interface to bridge
From: Eric W. Biederman @ 2007-12-06 6:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Chung-Chi Lo, netdev
In-Reply-To: <20071205225600.1feacfca@shemminger-laptop>
Stephen Hemminger <shemminger@linux-foundation.org> writes:
> On Wed, 5 Dec 2007 10:44:17 +0800
> "Chung-Chi Lo" <linolo@gmail.com> wrote:
>
>> My kernel is Linxu 2.6.22.1. SYSFS is off.
>> When adding an interface to bridge, console will show WARNING message.
>> If turn SYSFS to on, then the WARNING message is gone.
>> Any suggestion how to debug this problem? Thanks.
>>
>> # ifconfig eth0 0.0.0.0
>> eth0: starting interface.
>> # brctl addbr br0
>> # brctl addif br0 eth0
>> WARNING: at lib/kref.c:33 kref_get()
>> Call Trace:
>> [<80027844>] dump_stack+0x8/0x38
>> [<8011f348>] kref_get+0xdc/0xe4
>> [<8011ee20>] kobject_get+0x20/0x34
>> [<8011e910>] kobject_shadow_add+0x5c/0x170
>> [<8011ea34>] kobject_add+0x10/0x20
>> [<8020aac0>] br_add_if+0xb4/0x1b4
>> [<8020b354>] add_del_if+0x5c/0x118
>> [<8020bcc4>] br_dev_ioctl+0x6c/0x88
>> [<80182edc>] dev_ifsioc+0x334/0x3c0
>> [<80183184>] dev_ioctl+0x21c/0x2ec
>> [<8016f76c>] sock_ioctl+0x130/0x2e4
>> [<800b3b2c>] do_ioctl+0x6c/0x84
>> [<800b3d40>] vfs_ioctl+0x80/0x248
>> [<800b3f58>] sys_ioctl+0x50/0x98
>> [<8002a8a8>] stack_done+0x20/0x3c
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> This is an an artifact of the kobject_shadow code which was reverted in later
> kernels.
> It is gone in 2.6.23
I don't think it was the kobject_shadow, but rather we didn't initialize the kref
or something like that in net/core/dev.c
I believe commit 8b41d1887db718be9a2cd9e18c58ce25a4c7fd93 was the fix.
Disabling sysfs can be a fun exercise in finding corner case bugs right now.
Eric
^ permalink raw reply
* Re: [PATCH net-2.6.25 10/11][INET] Eliminate difference in actions of sysctl and proc handler for conf.all.forwarding
From: David Miller @ 2007-12-06 5:39 UTC (permalink / raw)
To: herbert; +Cc: xemul, netdev, devel
In-Reply-To: <E1J04N1-0006uU-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 06 Dec 2007 11:13:39 +1100
> David Miller <davem@davemloft.net> wrote:
> >
> > The user is pretty much screwed in one way or the other.
> > For example:
> >
> > 1) If 'default' propagates to all devices, any specific
> > setting for a device is lost.
> >
> > 2) If 'default' does not propagate, there is no way to
> > have 'default' influence devices which have already
> > been loaded.
>
> Well the way it works on IPv4 currently (for most options) is
> that we'll propagate default settings to a device until either:
>
> 1) the user modifies the setting for that device;
> 2) or that an IPv4 address has been added to the device.
>
> 2) was done to preserve backwards compatibility as the controls
> were previously only available after address addition and we did
> not propagate default settings in that case..
>
> We could easily extend this so that the default propagation
> worked until the user modified the setting, with an ioctl to
> revert to the current behaviour for compatibility.
Ok, this sounds like a good idea.
But we go back again to the question of how to get this "current
behavior" setting instantiated early enough. So much stuff happens
via initrd's etc. before the real userland has a change to run things,
read setting from the real filesystem config giles, in order to change
this.
^ permalink raw reply
* Re: [PATCH] fix br_fdb_fini() section mismatch
From: David Miller @ 2007-12-06 5:33 UTC (permalink / raw)
To: laforge; +Cc: netdev, linux-kernel
In-Reply-To: <20071206052658.GD30235@prithivi.gnumonks.org>
From: Harald Welte <laforge@gnumonks.org>
Date: Thu, 6 Dec 2007 10:56:58 +0530
> When compiling a kernel (current linus git or 2.6.24-rc4) with built-in
> CONFIG_BRIDGE, I get the following error:
>
> LD .tmp_vmlinux1
> `br_fdb_fini' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
> make: *** [.tmp_vmlinux1] Error 1
>
> This patch fixes it.
>
> Signed-off-by: Harald Welte <laforge@gnumonks.org>
Thanks, I already have this in my net-2.6.25 tree and will propagate
it to 2.6.24-rcX as well.
^ permalink raw reply
* Re: [PATCH] [TCP]: Make invariant check complain about invalid sacked_out
From: David Miller @ 2007-12-06 5:22 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0712052135530.9572@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Wed, 5 Dec 2007 21:36:37 +0200 (EET)
> On Wed, 5 Dec 2007, Ilpo Järvinen wrote:
>
> >
> > Earlier resolution for NewReno's sacked_out should now keep
> > it small enough for this to become invariant-like check.
> >
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> Forgot to modify it to the subject, this one to net-2.6.25 please.
Applied to net-2.6.25, thanks!
^ permalink raw reply
* Re: [PATCH net-2.6.25 3/3][ARP] Consolidate some code in arp_req_set/delete_publc
From: David Miller @ 2007-12-06 5:21 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4756DD74.4090304@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 05 Dec 2007 20:18:44 +0300
> The PROXY_ARP is set on devconfigs in a similar way in
> both calls.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Also applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-2.6.25 2/3][ARP] Minus one level of ndentation in arp_req_delete
From: David Miller @ 2007-12-06 5:20 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4756DD00.5030402@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 05 Dec 2007 20:16:48 +0300
> The same cleanup for deletion requests.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 1/3][ARP] Minus one level of indentation in arp_req_set
From: David Miller @ 2007-12-06 5:19 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4756DC96.7050700@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 05 Dec 2007 20:15:02 +0300
> The ATF_PUBL requests are handled completely separate from
> the others. Emphasize it with a separate function. This also
> reduces the indentation level.
>
> The same issue exists with the arp_delete_request, but
> when I tried to make it in one patch diff produced completely
> unreadable patch. So I split it into two, but they may be
> done with one commit.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25 3/3][ROUTE] Convert rt_hash_lock_init() macro into function
From: David Miller @ 2007-12-06 5:15 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4756DB47.7050403@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 05 Dec 2007 20:09:27 +0300
> There's no need in having this function exist in a form
> of macro. Properly formatted function looks much better.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25 2/3][ROUTE] Clean up proc files creation
From: David Miller @ 2007-12-06 5:14 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4756DA9F.4000200@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 05 Dec 2007 20:06:39 +0300
> The rt_cache, stats/rt_cache and rt_acct(optional) files
> creation looks a bit messy. Clean this out and join them
> to other proc-related functions under the proper ifdef.
>
> The struct net * argument in a new function will help net
> namespaces patches look nicer.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25 1/3][ROUTE] Collect proc-related functions together
From: David Miller @ 2007-12-06 5:13 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4756DA10.6000409@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Wed, 05 Dec 2007 20:04:16 +0300
> The net/ipv4/route.c file declares some entries for proc
> to dump some routing info. The reading functions are
> scattered over this file - collect them together.
>
> Besides, remove a useless IP_RT_ACCT_CPU macro.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: TCP event tracking via netlink...
From: David Miller @ 2007-12-06 5:03 UTC (permalink / raw)
To: johnpol; +Cc: jheffner, ilpo.jarvinen, netdev
In-Reply-To: <20071205144843.GB2623@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Wed, 5 Dec 2007 17:48:43 +0300
> On Wed, Dec 05, 2007 at 09:11:01AM -0500, John Heffner (jheffner@psc.edu) wrote:
> > >Maybe if we want to get really fancy we can have some more-expensive
> > >debug mode where detailed specific events get generated via some
> > >macros we can scatter all over the place. This won't be useful
> > >for general user problem analysis, but it will be excellent for
> > >developers.
> > >
> > >Let me know if you think this is useful enough and I'll work on
> > >an implementation we can start playing with.
> >
> >
> > FWIW, sounds similar to what these guys are doing with SIFTR for FreeBSD:
> > http://caia.swin.edu.au/urp/newtcp/tools.html
> > http://caia.swin.edu.au/reports/070824A/CAIA-TR-070824A.pdf
>
> And even more similar to this patch from Samir Bellabes of Mandriva:
> http://lwn.net/Articles/202255/
I think this work is very different.
When I say "state" I mean something more significant than
CLOSE, ESTABLISHED, etc. which is what Samir's patches are
tracking.
I'm talking about all of the sequence numbers, SACK information,
congestion control knobs, etc. whose values are nearly impossible to
track on a packet to packet basis in order to diagnose problems.
Web100 provided facilities along these lines as well.
^ permalink raw reply
* Re: TCP event tracking via netlink...
From: David Miller @ 2007-12-06 5:00 UTC (permalink / raw)
To: jheffner; +Cc: ilpo.jarvinen, netdev
In-Reply-To: <4756B175.5010108@psc.edu>
From: John Heffner <jheffner@psc.edu>
Date: Wed, 05 Dec 2007 09:11:01 -0500
> FWIW, sounds similar to what these guys are doing with SIFTR for FreeBSD:
> http://caia.swin.edu.au/urp/newtcp/tools.html
> http://caia.swin.edu.au/reports/070824A/CAIA-TR-070824A.pdf
Yes, my proposal is very similar to this SIFTR work.
In their work they tap into the stack using the packet filtering
hooks.
In this way they avoid having to make TCP stack modifications, they
just look up the PCB and dump state, whereas we have more liberty to
do more serious surgery :-)
^ permalink raw reply
* [PATCH 2.6.24 1/1]S2io: Check for register initialization completion before accesing device registers
From: Sreenivasa Honnur @ 2007-12-06 4:59 UTC (permalink / raw)
To: netdev, jeff; +Cc: support
- Making sure register initialisation is complete before proceeding further.
The driver must wait until initialization is complete before attempting to
access any other device registers.
Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
---
diff -Nurp patch_9/drivers/net/s2io.c patch_10/drivers/net/s2io.c
--- patch_9/drivers/net/s2io.c 2007-12-04 23:29:22.000000000 +0530
+++ patch_10/drivers/net/s2io.c 2007-12-04 23:36:48.000000000 +0530
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.6"
+#define DRV_VERSION "2.0.26.10"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
@@ -1100,6 +1100,20 @@ static int init_nic(struct s2io_nic *nic
msleep(500);
val64 = readq(&bar0->sw_reset);
+ /* Ensure that it's safe to access registers by checking
+ * RIC_RUNNING bit is reset. Check is valid only for XframeII.
+ */
+ if (nic->device_type == XFRAME_II_DEVICE) {
+ for (i = 0; i < 50; i++) {
+ val64 = readq(&bar0->adapter_status);
+ if (!(val64 & ADAPTER_STATUS_RIC_RUNNING))
+ break;
+ msleep(10);
+ }
+ if (i == 50)
+ return -ENODEV;
+ }
+
/* Enable Receiving broadcasts */
add = &bar0->mac_cfg;
val64 = readq(&bar0->mac_cfg);
diff -Nurp patch_9/drivers/net/s2io-regs.h patch_10/drivers/net/s2io-regs.h
--- patch_9/drivers/net/s2io-regs.h 2007-12-04 23:29:22.000000000 +0530
+++ patch_10/drivers/net/s2io-regs.h 2007-12-04 23:38:24.000000000 +0530
@@ -66,6 +66,7 @@ struct XENA_dev_config {
#define ADAPTER_STATUS_RC_PRC_QUIESCENT vBIT(0xFF,16,8)
#define ADAPTER_STATUS_MC_DRAM_READY s2BIT(24)
#define ADAPTER_STATUS_MC_QUEUES_READY s2BIT(25)
+#define ADAPTER_STATUS_RIC_RUNNING s2BIT(26)
#define ADAPTER_STATUS_M_PLL_LOCK s2BIT(30)
#define ADAPTER_STATUS_P_PLL_LOCK s2BIT(31)
^ 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