[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAATkVEyaocRcYJnfuQmGFAySBerQsXY44JDi4zjveP7TZNmu7Q@mail.gmail.com>
Date: Fri, 22 Jun 2012 17:12:07 -0400
From: Debabrata Banerjee <dbavatar@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Josh Hunt <johunt@...mai.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kaber@...sh.net" <kaber@...sh.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"pekkas@...core.fi" <pekkas@...core.fi>,
"kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Bug in net/ipv6/ip6_fib.c:fib6_dump_table()
On Fri, Jun 22, 2012 at 2:13 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Fri, 2012-06-22 at 08:44 -0500, Josh Hunt wrote:
>
>> Ahh. That makes sense and is what Alexey said before I just didn't put
>> it all together. So we are OK reverting this patch? I cannot find a path
>> where the walker's pointers are updated without the tb6_lock write_lock.
>>
>
> There was a bug somewhere, not sure we want to NULL dereference again.
>
As you identified, the tree seems to be protected by tb6_lock. I
couldn't find a race by inspection either. If this is not the root of
the problem, how would this patch fix it? So I think it does nothing.
We are attempting to reproduce that crash to prove it, but like Gao
feng I don't think we will see it.
My current favorite theory is that inet6_dump_fib was called with a
NULL func in callback. This looks like the approximate area of the
crash, but it's impossible to say without more information from
Patrick McHardy.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists