* Re: Linux 3.1-rc9
From: Simon Kirby @ 2011-11-02 19:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Gleixner, David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <1320256701.2292.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, Nov 02, 2011 at 06:58:21PM +0100, Eric Dumazet wrote:
> Le mercredi 02 novembre 2011 ?? 18:49 +0100, Eric Dumazet a ??crit :
> > Le mercredi 02 novembre 2011 ?? 18:27 +0100, Eric Dumazet a ??crit :
> >
> > > I believe it might come from commit 0e734419
> > > (ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
> > >
> > > In case inet_csk_route_child_sock() returns NULL, we dont release socket
> > > lock.
> > >
> > >
> >
> > Yes, thats the problem. I am testing following patch :
> >
> > diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > index 0ea10ee..683d97a 100644
> > --- a/net/ipv4/tcp_ipv4.c
> > +++ b/net/ipv4/tcp_ipv4.c
> > @@ -1510,6 +1510,7 @@ exit:
> > NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
> > return NULL;
> > put_and_exit:
> > + bh_unlock_sock(newsk);
> > sock_put(newsk);
> > goto exit;
> > }
> >
>
>
> This indeed solves the problem, but more closer inspection is needed to
> close all bugs, not this only one.
>
> # netstat -s
> Ip:
> 6961157 total packets received
> 0 forwarded
> 0 incoming packets discarded
> 6961157 incoming packets delivered
> 6961049 requests sent out
> 2 dropped because of missing route //// HERE, this is the origin
Actually, we have an anti-abuse daemon that injects blackhole routes, so
this makes sense. (The daemon was written before ipsets were merged and
normal netfilter rules make it fall over under attack.)
I'll try with this patch. Thanks!
Simon-
^ permalink raw reply
* Re: [PATCH] bridge: Reset IPCB on forward non-local packets in br_handle_frame_finish()
From: Vasily Averin @ 2011-11-02 19:11 UTC (permalink / raw)
Cc: David S. Miller, Stephen Hemminger, bridge, netdev, Herbert Xu,
devel
In-Reply-To: <4EB19549.4010601@parallels.com>
On 11/02/2011 11:08 PM, Vasily Averin wrote:
> if dst is not local br_handle_frame_finish() does not clone original skb and
> forgets to reset IPCB before return to IP stack. it can lead to stack corruption
> in icmp_send()
example of stack corruption
http://bugzilla.openvz.org/show_bug.cgi?id=2016
> Signed-off-by: Vasily Averin <vvs@sw.ru>
> ---
> net/bridge/br_input.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index f06ee39..6be8d00 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -93,10 +93,11 @@ int br_handle_frame_finish(struct sk_buff *skb)
> skb2 = skb;
>
> br->dev->stats.multicast++;
> - } else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
> + } else if ((dst = __br_fdb_get(br, dest)) != NULL) {
> skb2 = skb;
> /* Do not forward the packet since it's local. */
> - skb = NULL;
> + if (dst->is_local) {
> + skb = NULL;
> }
>
> if (skb) {
> -- 1.7.5.4
^ permalink raw reply
* [PATCH] bridge: Reset IPCB on forward non-local packets in br_handle_frame_finish()
From: Vasily Averin @ 2011-11-02 19:08 UTC (permalink / raw)
To: David S. Miller, Stephen Hemminger; +Cc: bridge, netdev, Herbert Xu, devel
if dst is not local br_handle_frame_finish() does not clone original skb and
forgets to reset IPCB before return to IP stack. it can lead to stack corruption
in icmp_send()
Signed-off-by: Vasily Averin <vvs@sw.ru>
---
net/bridge/br_input.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f06ee39..6be8d00 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -93,10 +93,11 @@ int br_handle_frame_finish(struct sk_buff *skb)
skb2 = skb;
br->dev->stats.multicast++;
- } else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
+ } else if ((dst = __br_fdb_get(br, dest)) != NULL) {
skb2 = skb;
/* Do not forward the packet since it's local. */
- skb = NULL;
+ if (dst->is_local) {
+ skb = NULL;
}
if (skb) {
-- 1.7.5.4
^ permalink raw reply related
* Re: Linux 3.1-rc9
From: Thomas Gleixner @ 2011-11-02 18:30 UTC (permalink / raw)
To: Simon Kirby
Cc: David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <20111102182812.GE5971@hostway.ca>
On Wed, 2 Nov 2011, Simon Kirby wrote:
> On Wed, Nov 02, 2011 at 05:40:53PM +0100, Thomas Gleixner wrote:
> Ok, I'll try this. Hmm, all CPUs typically try to grab the lock fairly
> quickly after it happens, which could make it difficult to cat the file.
> I'll try ftrace_dump(DUMP_ALL); in there instead.
Eric has spotted the source of trouble already. Can you try his patch
first? If it still persists, we still can resort to hardcore tracing :)
Thanks,
tglx
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Simon Kirby @ 2011-11-02 18:28 UTC (permalink / raw)
To: Thomas Gleixner
Cc: David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <alpine.LFD.2.02.1111021725550.2829@ionos>
On Wed, Nov 02, 2011 at 05:40:53PM +0100, Thomas Gleixner wrote:
> On Mon, 31 Oct 2011, Simon Kirby wrote:
>
> > One more, again a bit different. The last few lockups have looked like
> > this. Not sure why, but we're hitting this at a few a day now. Thomas,
> > this is without your patch, but as you said, that's right before a free
> > and should print a separate lockdep warning.
> >
> > No "huh" lines until after the trace on this one. I'll move to 3.1 with
>
> That means that the lockdep warning hit in the same net_rx cycle
> before the leak was detected by the softirq code.
>
> > cherry-picked b0691c8e now.
>
> Can you please add the debug patch below and try the following:
>
> Enable CONFIG_FUNCTION_TRACER & CONFIG_FUNCTION_GRAPH_TRACER
>
> # cd $DEBUGFSMOUNTPOINT/tracing
> # echo sk_clone >set_ftrace_filter
> # echo function >current_tracer
> # echo 1 >options/func_stack_trace
>
> Now wait until it reproduces (which stops the trace) and read out
>
> # cat trace >/tmp/trace.txt
>
> Please provide the trace file along with the lockdep splat. That
> should tell us which callchain is responsible for the spinlock
> leakage.
> Thanks,
>
> tglx
>
> --------------->
> kernel/softirq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-2.6/kernel/softirq.c
> ===================================================================
> --- linux-2.6.orig/kernel/softirq.c
> +++ linux-2.6/kernel/softirq.c
> @@ -238,6 +238,7 @@ restart:
> h->action(h);
> trace_softirq_exit(vec_nr);
> if (unlikely(prev_count != preempt_count())) {
> + tracing_off();
> printk(KERN_ERR "huh, entered softirq %u %s %p"
> "with preempt_count %08x,"
> " exited with %08x?\n", vec_nr,
Ok, I'll try this. Hmm, all CPUs typically try to grab the lock fairly
quickly after it happens, which could make it difficult to cat the file.
I'll try ftrace_dump(DUMP_ALL); in there instead.
Simon-
^ permalink raw reply
* RE: bnx2x kerneloops
From: Dmitry Kravkov @ 2011-11-02 18:19 UTC (permalink / raw)
To: Carlos Peón Costa; +Cc: netdev@vger.kernel.org
In-Reply-To: <SNT113-W38A7D5A673342F70A1F808DBD40@phx.gbl>
On Wed, 2011-11-02 at 04:59 -0700, Carlos Peón Costa wrote:
>
> Hi, It's a HP BL460c G6.
> Regards.
It looks like problem happened before the WATCHDOG, FW has asserted for
some reason.
Can you provide /var/log/messages and describe in details the scenario?
Thanks
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Linus Torvalds @ 2011-11-02 18:10 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Gleixner, Simon Kirby, David Miller, Peter Zijlstra,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <1320257141.2292.24.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, Nov 2, 2011 at 11:05 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Yes, but only when tproxy is used, and in some obscure error
> conditions... Probably nobody ever hit them or complained.
Yes, I'm not disputing that. However, it does show how incredibly
fragile that code is.
May I suggest renaming those "clone_sk()" kinds of functions
"clone_sk_lock()" or something? So that you *see* that it's locked as
it is cloned. That might have made the bug not happen in the first
place..
Of course, maybe it's obvious to most net people - just not me looking
at the code - that the new socket ended up being locked at allocation.
But considering the bug happened twice, that "obvious" part is clearly
debatable..
Linus
^ permalink raw reply
* wireless git trees returning to kernel.org
From: John W. Linville @ 2011-11-02 18:09 UTC (permalink / raw)
To: linux-wireless
Cc: David Woodhouse, Stephen Rothwell, David S. Miller, netdev,
linux-kernel
FYI...
I have migrated the wireless git trees back to the kernel.org
infrastructure. As of right now, the trees are identical between
kernel.org and infradead.org. Further updates likely will only go
to kernel.org, so plan accordingly.
The "current" wireless tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
The "next" wireless tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git
The "testing" wireless tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
Please do the needful!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Eric Dumazet @ 2011-11-02 18:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Simon Kirby, David Miller, Peter Zijlstra,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <CA+55aFzYHJcGEmuj900G60DECBvdWDWNC09N393PWutsFUL-oQ@mail.gmail.com>
Le mercredi 02 novembre 2011 à 11:00 -0700, Linus Torvalds a écrit :
> On Wed, Nov 2, 2011 at 10:53 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > tcp_v4_syn_recv_sock()
> > {
> > newsk = tcp_create_openreq_child(sk, req, skb);
> >
> > newsk is locked at this point.
>
> Umm, if that is the case, then the bug predates the commit you point
> to. There were exit paths before that too.
>
Yes, but only when tproxy is used, and in some obscure error
conditions... Probably nobody ever hit them or complained.
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Eric Dumazet @ 2011-11-02 18:04 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Simon Kirby, David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <alpine.LFD.2.02.1111021849170.2829@ionos>
Le mercredi 02 novembre 2011 à 18:54 +0100, Thomas Gleixner a écrit :
> The same applies for if (__inet_inherit_port(sk, newsk) < 0) a few
> lines further down, but that part was leaking the lock before that
> commit already.
>
Yes, but in normal condition, this never happened, this is why this
problem was never noticed.
tproxy is probaby very seldom used, and when used the error path is
probably never reached...
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Linus Torvalds @ 2011-11-02 18:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Gleixner, Simon Kirby, David Miller, Peter Zijlstra,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <1320256412.2292.17.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, Nov 2, 2011 at 10:53 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> tcp_v4_syn_recv_sock()
> {
> newsk = tcp_create_openreq_child(sk, req, skb);
>
> newsk is locked at this point.
Umm, if that is the case, then the bug predates the commit you point
to. There were exit paths before that too.
Linus
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Eric Dumazet @ 2011-11-02 17:58 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Simon Kirby, David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <1320256157.2292.15.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le mercredi 02 novembre 2011 à 18:49 +0100, Eric Dumazet a écrit :
> Le mercredi 02 novembre 2011 à 18:27 +0100, Eric Dumazet a écrit :
>
> > I believe it might come from commit 0e734419
> > (ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
> >
> > In case inet_csk_route_child_sock() returns NULL, we dont release socket
> > lock.
> >
> >
>
> Yes, thats the problem. I am testing following patch :
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 0ea10ee..683d97a 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1510,6 +1510,7 @@ exit:
> NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
> return NULL;
> put_and_exit:
> + bh_unlock_sock(newsk);
> sock_put(newsk);
> goto exit;
> }
>
This indeed solves the problem, but more closer inspection is needed to
close all bugs, not this only one.
# netstat -s
Ip:
6961157 total packets received
0 forwarded
0 incoming packets discarded
6961157 incoming packets delivered
6961049 requests sent out
2 dropped because of missing route //// HERE, this is the origin
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Thomas Gleixner @ 2011-11-02 17:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: Simon Kirby, David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <1320254854.2292.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2793 bytes --]
On Wed, 2 Nov 2011, Eric Dumazet wrote:
> Le mercredi 02 novembre 2011 à 17:40 +0100, Thomas Gleixner a écrit :
> > On Mon, 31 Oct 2011, Simon Kirby wrote:
> > > On Tue, Oct 25, 2011 at 01:20:49PM -0700, Simon Kirby wrote:
> > >
> > > > On Mon, Oct 24, 2011 at 12:02:03PM -0700, Simon Kirby wrote:
> > > >
> > > > > Ok, hit the hang about 4 more times, but only this morning on a box with
> > > > > a serial cable attached. Yay!
> > > >
> > > > Here's lockdep output from another box. This one looks a bit different.
> > >
> > > One more, again a bit different. The last few lockups have looked like
> > > this. Not sure why, but we're hitting this at a few a day now. Thomas,
> > > this is without your patch, but as you said, that's right before a free
> > > and should print a separate lockdep warning.
> > >
> > > No "huh" lines until after the trace on this one. I'll move to 3.1 with
> >
> > That means that the lockdep warning hit in the same net_rx cycle
> > before the leak was detected by the softirq code.
> >
> > > cherry-picked b0691c8e now.
> >
> > Can you please add the debug patch below and try the following:
> >
> > Enable CONFIG_FUNCTION_TRACER & CONFIG_FUNCTION_GRAPH_TRACER
> >
> > # cd $DEBUGFSMOUNTPOINT/tracing
> > # echo sk_clone >set_ftrace_filter
> > # echo function >current_tracer
> > # echo 1 >options/func_stack_trace
> >
> > Now wait until it reproduces (which stops the trace) and read out
> >
> > # cat trace >/tmp/trace.txt
> >
> > Please provide the trace file along with the lockdep splat. That
> > should tell us which callchain is responsible for the spinlock
> > leakage.
> >
> > Thanks,
> >
> > tglx
> >
> > --------------->
> > kernel/softirq.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > Index: linux-2.6/kernel/softirq.c
> > ===================================================================
> > --- linux-2.6.orig/kernel/softirq.c
> > +++ linux-2.6/kernel/softirq.c
> > @@ -238,6 +238,7 @@ restart:
> > h->action(h);
> > trace_softirq_exit(vec_nr);
> > if (unlikely(prev_count != preempt_count())) {
> > + tracing_off();
> > printk(KERN_ERR "huh, entered softirq %u %s %p"
> > "with preempt_count %08x,"
> > " exited with %08x?\n", vec_nr,
>
>
> I believe it might come from commit 0e734419
> (ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
>
> In case inet_csk_route_child_sock() returns NULL, we dont release socket
> lock.
The same applies for if (__inet_inherit_port(sk, newsk) < 0) a few
lines further down, but that part was leaking the lock before that
commit already.
Just for the record, the locking in that code is mind boggling. It
took me some detective work to find even the place where the success
code path unlocks the lock :(
Thanks,
tglx
^ permalink raw reply
* Re: [LARTC] LARTC mailing list
From: Benjamin Poirier @ 2011-11-02 17:54 UTC (permalink / raw)
To: Andrew Beverley
Cc: Linux Advanced Routing & Traffic Control project,
linux-new-lists, netfilter, netdev
In-Reply-To: <1319292634.26402.6302.camel@andybev-desktop>
On 11/10/22 15:10, Andrew Beverley wrote:
> On Sat, 2011-10-22 at 15:03 +0200, Niccolò Belli wrote:
> > Is someone still interested to bring LARTC to a new life?
> > I'm sorry for the subscription but the list didn't work anymore and it
> > was unfeasible to CC 30+ addresses. Let me know if you want to
> > unsubscribe and you don't know how to.
>
> Thanks for doing this Niccolo. However, I'd rather see it hosted at
> vger.kernel.org for all the reasons previously outlined.
>
> I was actually going to suggest a new list called net-users instead.
> There is netdev, netfilter-devel and netfilter, but not a general
> networking users list.
Isn't that what linux-net@vger.kernel.org is/was supposed to be about?
Not sure what's its status, it's no longer listed on
http://vger.kernel.org/vger-lists.html, the last message I've received
on it was a month ago and it was mostly spam before that.
-Ben
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Eric Dumazet @ 2011-11-02 17:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Simon Kirby, David Miller, Peter Zijlstra,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <CA+55aFxKtA0XXtiKgKC5qHmFuTv2=TbuMEczkegJKY4Uy00a-g@mail.gmail.com>
Le mercredi 02 novembre 2011 à 10:46 -0700, Linus Torvalds a écrit :
> On Wed, Nov 2, 2011 at 10:27 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > I believe it might come from commit 0e734419
> > (ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
> >
> > In case inet_csk_route_child_sock() returns NULL, we dont release socket
> > lock.
>
> Hmm. I'm not seeing it. We're not even taking the socket lock there.
> Or is it hidden somehow?
>
> Linus
tcp_v4_syn_recv_sock()
{
newsk = tcp_create_openreq_child(sk, req, skb);
...
}
newsk is locked at this point.
^ permalink raw reply
* Re: Subnet router anycast for FE80/10 ?
From: David Stevens @ 2011-11-02 17:52 UTC (permalink / raw)
To: David Lamparter; +Cc: Andreas Hofmeister, netdev, netdev-owner
In-Reply-To: <20111102153809.GH297914@jupiter.n2.diac24.net>
netdev-owner@vger.kernel.org wrote on 11/02/2011 08:38:09 AM:
> From: David Lamparter <equinox@diac24.net>
> > This address seems not to be explicitly mentioned in any RFC, but RFC
> > 4291 says "All routers are required to support the Subnet-Router
anycast
> > addresses for the subnets to which they have interfaces."
>
> That this directly contradicts RFC 2526 which specifies the
> subnet-router anycast address to be either ::ffff:ffff:ffff:ff80 or
> ::fcff:ffff:ffff:ff80 depending on the phase of the moon (well,
> interface type actually, but same thing. Also, the /64 <> /10
> distinction would matter here.)
The subnet-router anycast address is defined in section 2.6.1 of
RFC 4291
to be "all 0's" for the prefix. The definition above is for reserved
anycast
addresses. RFC 2526 says "IPv6 defines a required Subnet-Router anycast
address [3]
for all routers within a subnet prefix, and allows additional anycast
addresses to
be taken from the unicast address space. This document defines an
additional set
of reserved anycast addresses...".
>
> ... it's actually fairly hard to implement this at all. The idea of
> "Anycast" is that even if you have 1000 routers, only one router will
> receive the packet. The network is supposed to magically take care of
> that, but in reality this only works with Layer 3/IPv6
The host implementation is very straightforward. Not every host
on a segment has to use the *same* host for an anycast address (it's
kind of the point that it won't, in fact). A host simply needs to
do a solicitation for the anycast address and keep the first one that
answers (by definition, the "closest").
+-DLS
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Eric Dumazet @ 2011-11-02 17:49 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Simon Kirby, David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <1320254854.2292.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le mercredi 02 novembre 2011 à 18:27 +0100, Eric Dumazet a écrit :
> I believe it might come from commit 0e734419
> (ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
>
> In case inet_csk_route_child_sock() returns NULL, we dont release socket
> lock.
>
>
Yes, thats the problem. I am testing following patch :
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0ea10ee..683d97a 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1510,6 +1510,7 @@ exit:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
return NULL;
put_and_exit:
+ bh_unlock_sock(newsk);
sock_put(newsk);
goto exit;
}
^ permalink raw reply related
* Re: Linux 3.1-rc9
From: Linus Torvalds @ 2011-11-02 17:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Gleixner, Simon Kirby, David Miller, Peter Zijlstra,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <1320254854.2292.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, Nov 2, 2011 at 10:27 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> I believe it might come from commit 0e734419
> (ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
>
> In case inet_csk_route_child_sock() returns NULL, we dont release socket
> lock.
Hmm. I'm not seeing it. We're not even taking the socket lock there.
Or is it hidden somehow?
Linus
^ permalink raw reply
* Re: Subnet router anycast for FE80/10 ?
From: David Stevens @ 2011-11-02 17:33 UTC (permalink / raw)
To: Andreas Hofmeister; +Cc: netdev, netdev-owner
In-Reply-To: <4EAF0391.80907@collax.com>
netdev-owner@vger.kernel.org wrote on 10/31/2011 01:22:41 PM:
> But then, FE80/10 is not actually supposed to be routed at all and so a
> router cannot not really be a router for that particular subnet ?
>
> Or is "FE80::" just supposed to be the anycast equivalent for the "all
> routers" multicast address ff02::2 ?
>
> Maybe someone on this list could enlighten me.
I think it's just a matter of not making an exception for LL addresses.
Forwarding is for the interface, not for individual prefixes.
If forwarding is enabled on the interface, anycast addresses for all
its prefixes are added.
It could be used to send to "any router" on a subnet, of course.
+-DLS
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Eric Dumazet @ 2011-11-02 17:27 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Simon Kirby, David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <alpine.LFD.2.02.1111021725550.2829@ionos>
Le mercredi 02 novembre 2011 à 17:40 +0100, Thomas Gleixner a écrit :
> On Mon, 31 Oct 2011, Simon Kirby wrote:
> > On Tue, Oct 25, 2011 at 01:20:49PM -0700, Simon Kirby wrote:
> >
> > > On Mon, Oct 24, 2011 at 12:02:03PM -0700, Simon Kirby wrote:
> > >
> > > > Ok, hit the hang about 4 more times, but only this morning on a box with
> > > > a serial cable attached. Yay!
> > >
> > > Here's lockdep output from another box. This one looks a bit different.
> >
> > One more, again a bit different. The last few lockups have looked like
> > this. Not sure why, but we're hitting this at a few a day now. Thomas,
> > this is without your patch, but as you said, that's right before a free
> > and should print a separate lockdep warning.
> >
> > No "huh" lines until after the trace on this one. I'll move to 3.1 with
>
> That means that the lockdep warning hit in the same net_rx cycle
> before the leak was detected by the softirq code.
>
> > cherry-picked b0691c8e now.
>
> Can you please add the debug patch below and try the following:
>
> Enable CONFIG_FUNCTION_TRACER & CONFIG_FUNCTION_GRAPH_TRACER
>
> # cd $DEBUGFSMOUNTPOINT/tracing
> # echo sk_clone >set_ftrace_filter
> # echo function >current_tracer
> # echo 1 >options/func_stack_trace
>
> Now wait until it reproduces (which stops the trace) and read out
>
> # cat trace >/tmp/trace.txt
>
> Please provide the trace file along with the lockdep splat. That
> should tell us which callchain is responsible for the spinlock
> leakage.
>
> Thanks,
>
> tglx
>
> --------------->
> kernel/softirq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-2.6/kernel/softirq.c
> ===================================================================
> --- linux-2.6.orig/kernel/softirq.c
> +++ linux-2.6/kernel/softirq.c
> @@ -238,6 +238,7 @@ restart:
> h->action(h);
> trace_softirq_exit(vec_nr);
> if (unlikely(prev_count != preempt_count())) {
> + tracing_off();
> printk(KERN_ERR "huh, entered softirq %u %s %p"
> "with preempt_count %08x,"
> " exited with %08x?\n", vec_nr,
I believe it might come from commit 0e734419
(ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
In case inet_csk_route_child_sock() returns NULL, we dont release socket
lock.
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Thomas Gleixner @ 2011-11-02 16:40 UTC (permalink / raw)
To: Simon Kirby
Cc: David Miller, Peter Zijlstra, Linus Torvalds,
Linux Kernel Mailing List, Dave Jones, Martin Schwidefsky,
Ingo Molnar, Network Development
In-Reply-To: <20111031173246.GA10614@hostway.ca>
On Mon, 31 Oct 2011, Simon Kirby wrote:
> On Tue, Oct 25, 2011 at 01:20:49PM -0700, Simon Kirby wrote:
>
> > On Mon, Oct 24, 2011 at 12:02:03PM -0700, Simon Kirby wrote:
> >
> > > Ok, hit the hang about 4 more times, but only this morning on a box with
> > > a serial cable attached. Yay!
> >
> > Here's lockdep output from another box. This one looks a bit different.
>
> One more, again a bit different. The last few lockups have looked like
> this. Not sure why, but we're hitting this at a few a day now. Thomas,
> this is without your patch, but as you said, that's right before a free
> and should print a separate lockdep warning.
>
> No "huh" lines until after the trace on this one. I'll move to 3.1 with
That means that the lockdep warning hit in the same net_rx cycle
before the leak was detected by the softirq code.
> cherry-picked b0691c8e now.
Can you please add the debug patch below and try the following:
Enable CONFIG_FUNCTION_TRACER & CONFIG_FUNCTION_GRAPH_TRACER
# cd $DEBUGFSMOUNTPOINT/tracing
# echo sk_clone >set_ftrace_filter
# echo function >current_tracer
# echo 1 >options/func_stack_trace
Now wait until it reproduces (which stops the trace) and read out
# cat trace >/tmp/trace.txt
Please provide the trace file along with the lockdep splat. That
should tell us which callchain is responsible for the spinlock
leakage.
Thanks,
tglx
--------------->
kernel/softirq.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/kernel/softirq.c
===================================================================
--- linux-2.6.orig/kernel/softirq.c
+++ linux-2.6/kernel/softirq.c
@@ -238,6 +238,7 @@ restart:
h->action(h);
trace_softirq_exit(vec_nr);
if (unlikely(prev_count != preempt_count())) {
+ tracing_off();
printk(KERN_ERR "huh, entered softirq %u %s %p"
"with preempt_count %08x,"
" exited with %08x?\n", vec_nr,
^ permalink raw reply
* [PATCH 6/6] [6LoWPAN] update documentation
From: Alexander Smirnov @ 2011-11-02 16:35 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111102162520.GA2669-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
This patch adds chapter to documentation which describes how to use
6lowpan technology.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/networking/ieee802154.txt | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 23c995e..7d50b26 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -78,3 +78,29 @@ in software. This is currently WIP.
See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
+6LoWPAN Linux implementation
+============================
+
+The IEEE 802.15.4 standard specifies an MTU of 128 bytes, yielding about 80
+octets of actual MAC payload once security is turned on, on a wireless link
+with a link throughput of 250 kbps or less. The 6LoWPAN adaptation format
+[RFC4944] was specified to carry IPv6 datagrams over such constrained links,
+taking into account limited bandwidth, memory, or energy resources that are
+expected in applications such as wireless Sensor Networks. [RFC4944] defines
+a Mesh Addressing header to support sub-IP forwarding, a Fragmentation header
+to support the IPv6 minimum MTU requirement [RFC2460], and stateless header
+compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the
+relatively large IPv6 and UDP headers down to (in the best case) several bytes.
+
+All the code related to 6lowpan you may find in files: net/ieee802154/6lowpan.*
+
+To setup 6lowpan interface you need:
+1. Add IEEE802.15.4 interface and initialize PANid;
+2. Add 6lowpan interface by command like:
+ # ip link add link wpan0 name lowpan0 type lowpan
+3. Set MAC (if needs):
+ # ip link set lowpan0 address de:ad:be:ef:ca:fe:ba:be
+4. Bring up 'lowpan0' interface
+
+
+
--
1.7.2.5
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
^ permalink raw reply related
* [PATCH 5/6] [6LoWPAN] UDP header decompression
From: Alexander Smirnov @ 2011-11-02 16:35 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111102162520.GA2669-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
This patch provides possibility to decompress UDP headers.
Derived from Contiki OS.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 6da3357..49f42a8 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -839,7 +839,55 @@ lowpan_process_data(struct sk_buff *skb)
goto drop;
}
- /* TODO: UDP header parse */
+ /* UDP data uncompression */
+ if (iphc0 & LOWPAN_IPHC_NH_C) {
+ tmp = lowpan_fetch_skb_u8(skb);
+
+ if ((tmp & LOWPAN_NHC_UDP_MASK) == LOWPAN_NHC_UDP_ID) {
+ struct udphdr *uh = udp_hdr(skb);
+
+ pr_debug("(%s): UDP header uncompression\n", __func__);
+ switch (tmp & LOWPAN_NHC_UDP_CS_P_11) {
+ case LOWPAN_NHC_UDP_CS_P_00:
+ memcpy(&uh->source, &skb->data[0], 2);
+ memcpy(&uh->dest, &skb->data[2], 2);
+ skb_pull(skb, 4);
+ break;
+ case LOWPAN_NHC_UDP_CS_P_01:
+ memcpy(&uh->source, &skb->data[0], 2);
+ uh->dest =
+ skb->data[2] + LOWPAN_NHC_UDP_8BIT_PORT;
+ skb_pull(skb, 3);
+ break;
+ case LOWPAN_NHC_UDP_CS_P_10:
+ uh->source = skb->data[0] + LOWPAN_NHC_UDP_8BIT_PORT;
+ memcpy(&uh->dest, &skb->data[1], 2);
+ skb_pull(skb, 3);
+ break;
+ case LOWPAN_NHC_UDP_CS_P_11:
+ uh->source =
+ LOWPAN_NHC_UDP_4BIT_PORT + (skb->data[0] >> 4);
+ uh->dest =
+ LOWPAN_NHC_UDP_4BIT_PORT + (skb->data[0] & 0x0f);
+ skb_pull(skb, 1);
+ break;
+ default:
+ pr_debug("(%s) ERROR: unknown UDP format\n", __func__);
+ goto drop;
+ }
+
+ pr_debug("(%s): uncompressed UDP ports: src = %d, dst = %d\n",
+ __func__, uh->source, uh->dest);
+
+ /* copy checksum */
+ memcpy(&uh->check, &skb->data[0], 2);
+ skb_pull(skb, 2);
+ } else {
+ pr_debug("(%s): ERROR: unsupported NH format\n",
+ __func__);
+ goto drop;
+ }
+ }
/* Not fragmented package */
hdr.payload_len = htons(skb->len);
--
1.7.2.5
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
^ permalink raw reply related
* [PATCH 4/6] [6LoWPAN] UDP header compression
From: Alexander Smirnov @ 2011-11-02 16:35 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111102162520.GA2669-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
This patch adds support for UDP header compression.
Derived from Contiki OS.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 51 ++++++++++++++++++++++++++++++++++++++++++---
net/ieee802154/6lowpan.h | 5 ++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index c4aae4e..6da3357 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -365,8 +365,6 @@ static int lowpan_header_create(struct sk_buff *skb,
if (hdr->nexthdr == UIP_PROTO_UDP)
iphc0 |= LOWPAN_IPHC_NH_C;
-/* TODO: next header compression */
-
if ((iphc0 & LOWPAN_IPHC_NH_C) == 0) {
*hc06_ptr = hdr->nexthdr;
hc06_ptr += 1;
@@ -454,8 +452,53 @@ static int lowpan_header_create(struct sk_buff *skb,
}
}
- /* TODO: UDP header compression */
- /* TODO: Next Header compression */
+ /* UDP header compression */
+ if (hdr->nexthdr == UIP_PROTO_UDP) {
+ struct udphdr *uh = udp_hdr(skb);
+
+ pr_debug("(%s): UDP header compression\n", __func__);
+
+ if (((uh->source & LOWPAN_NHC_UDP_4BIT_MASK) ==
+ LOWPAN_NHC_UDP_4BIT_PORT) &&
+ ((uh->dest & LOWPAN_NHC_UDP_4BIT_MASK) ==
+ LOWPAN_NHC_UDP_4BIT_PORT)) {
+ pr_debug("(%s): both ports compression to 4 bits\n",
+ __func__);
+ *hc06_ptr = LOWPAN_NHC_UDP_CS_P_11;
+ *(hc06_ptr + 1) = /* subtraction is faster */
+ (u8)((uh->dest - LOWPAN_NHC_UDP_4BIT_PORT) +
+ ((uh->source & LOWPAN_NHC_UDP_4BIT_PORT) << 4));
+ hc06_ptr += 2;
+ } else if ((uh->dest & LOWPAN_NHC_UDP_8BIT_MASK) ==
+ LOWPAN_NHC_UDP_8BIT_PORT) {
+ pr_debug("(%s): remove 8 bits of dest\n", __func__);
+ *hc06_ptr = LOWPAN_NHC_UDP_CS_P_01;
+ memcpy(hc06_ptr + 1, &uh->source, 2);
+ *(hc06_ptr + 3) =
+ (u8)(uh->dest - LOWPAN_NHC_UDP_8BIT_PORT);
+ hc06_ptr += 4;
+ } else if ((uh->source & LOWPAN_NHC_UDP_8BIT_MASK) ==
+ LOWPAN_NHC_UDP_8BIT_PORT) {
+ pr_debug("(%s): remove 8 bits of source\n", __func__);
+ *hc06_ptr = LOWPAN_NHC_UDP_CS_P_10;
+ memcpy(hc06_ptr + 1, &uh->dest, 2);
+ *(hc06_ptr + 3) =
+ (u8)(uh->source - LOWPAN_NHC_UDP_8BIT_PORT);
+ hc06_ptr += 4;
+ } else {
+ pr_debug("(%s): can't compress header\n", __func__);
+ *hc06_ptr = LOWPAN_NHC_UDP_CS_P_00;
+ memcpy(hc06_ptr + 1, &uh->source, 2);
+ memcpy(hc06_ptr + 3, &uh->dest, 2);
+ hc06_ptr += 5;
+ }
+
+ /* checksum is always inline */
+ memcpy(hc06_ptr, &uh->check, 2);
+ hc06_ptr += 2;
+ }
+
+ /* TODO: other NH types support? */
head[0] = iphc0;
head[1] = iphc1;
diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 5d2e5a0..aeff3f3 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h
@@ -219,6 +219,11 @@
#define LOWPAN_NHC_UDP_CHECKSUMC 0x04
#define LOWPAN_NHC_UDP_CHECKSUMI 0x00
+#define LOWPAN_NHC_UDP_4BIT_PORT 0xF0B0
+#define LOWPAN_NHC_UDP_4BIT_MASK 0xFFF0
+#define LOWPAN_NHC_UDP_8BIT_PORT 0xF000
+#define LOWPAN_NHC_UDP_8BIT_MASK 0xFF00
+
/* values for port compression, _with checksum_ ie bit 5 set to 0 */
#define LOWPAN_NHC_UDP_CS_P_00 0xF0 /* all inline */
#define LOWPAN_NHC_UDP_CS_P_01 0xF1 /* source 16bit inline,
--
1.7.2.5
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
^ permalink raw reply related
* [PATCH 2/6] [6LoWPAN] disable debugging by default
From: Alexander Smirnov @ 2011-11-02 16:34 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111102162520.GA2669-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
This patch disables debug output enabled by default.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 890ecef..e5709fa 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -50,8 +50,6 @@
* SUCH DAMAGE.
*/
-#define DEBUG
-
#include <linux/bitops.h>
#include <linux/if_arp.h>
#include <linux/module.h>
--
1.7.2.5
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
^ permalink raw reply related
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