From: David Ahern <dsahern@gmail.com>
To: Ben Greear <greearb@candelatech.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>, netdev <netdev@vger.kernel.org>
Subject: Re: Repeatable inet6_dump_fib crash in stock 4.12.0-rc4+
Date: Tue, 13 Jun 2017 14:28:22 -0600 [thread overview]
Message-ID: <42400e72-d93d-4c2b-7864-efd40e0bd981@gmail.com> (raw)
In-Reply-To: <9cb61ef0-37c0-8f35-bb5c-e3d8e63cbe2f@candelatech.com>
On 6/13/17 2:16 PM, Ben Greear wrote:
> On 06/09/2017 02:25 PM, Eric Dumazet wrote:
>> On Fri, 2017-06-09 at 07:27 -0600, David Ahern wrote:
>>> On 6/8/17 11:55 PM, Cong Wang wrote:
>>>> On Thu, Jun 8, 2017 at 2:27 PM, Ben Greear <greearb@candelatech.com>
>>>> wrote:
>>>>>
>>>>> As far as I can tell, the patch did not help, or at least we still
>>>>> reproduce
>>>>> the
>>>>> crash easily.
>>>>
>>>> netlink dump is serialized by nlk->cb_mutex so I don't think that
>>>> patch makes any sense w.r.t race condition.
>>>
>>> From what I can see fn_sernum should be accessed under table lock, so
>>> when saving and checking it during a walk make sure it the lock is held.
>>> That has nothing to do with the netlink dump, but the table changing
>>> during a walk.
>>
>>
>> Yes, your patch makes total sense, of course.
>
> I guess someone should go ahead and make an official patch and
> submit it, even if it doesn't fix my problem.
I can do that; was hoping to root cause the problem first.
>
>>>>> (gdb) l *(fib6_walk_continue+0x76)
>>>>> 0x188c6 is in fib6_walk_continue
>>>>> (/home/greearb/git/linux-2.6/net/ipv6/ip6_fib.c:1593).
>>>>> 1588 if (fn == w->root)
>>>>> 1589 return 0;
>>>>> 1590 pn = fn->parent;
>>>>> 1591 w->node = pn;
>>>>> 1592 #ifdef CONFIG_IPV6_SUBTREES
>>>>> 1593 if (FIB6_SUBTREE(pn) == fn) {
>>>>
>>>> Apparently fn->parent is NULL here for some reason, but
>>>> I don't know if that is expected or not. If a simple NULL check
>>>> is not enough here, we have to trace why it is NULL.
>>>
>>> From my understanding, parent should not be null hence the attempts to
>>> fix access to table nodes under a lock. ie., figuring out why it is null
>>> here.
>
> If someone has more suggestions, I'll be happy to test.
I have looked at the code again and nothing is jumping out. Will look
again later today.
next prev parent reply other threads:[~2017-06-13 20:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 21:06 Repeatable inet6_dump_fib crash in stock 4.12.0-rc4+ Ben Greear
2017-06-07 0:00 ` David Ahern
2017-06-07 0:27 ` Eric Dumazet
2017-06-07 0:34 ` David Ahern
2017-06-07 4:19 ` Eric Dumazet
2017-06-08 21:27 ` Ben Greear
2017-06-09 5:55 ` Cong Wang
2017-06-09 13:27 ` David Ahern
2017-06-09 21:25 ` Eric Dumazet
2017-06-13 20:16 ` Ben Greear
2017-06-13 20:28 ` David Ahern [this message]
2017-06-13 20:39 ` Ben Greear
2017-06-13 21:42 ` Cong Wang
2017-06-14 2:27 ` David Ahern
2017-06-14 22:23 ` Ben Greear
2017-06-14 22:25 ` David Ahern
2017-06-20 14:12 ` Ben Greear
2017-06-20 18:05 ` Michal Kubecek
2017-06-20 21:41 ` Ben Greear
2017-06-21 3:03 ` David Ahern
2017-06-25 21:59 ` David Ahern
2018-01-24 23:59 ` Ben Greear
2018-04-17 23:29 ` Ben Greear
2018-04-18 0:38 ` David Ahern
2017-06-07 0:48 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42400e72-d93d-4c2b-7864-efd40e0bd981@gmail.com \
--to=dsahern@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=greearb@candelatech.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.