Re: [PATCH net] ipv6: remove incorrect WARN_ON() in fib6_del()
From: Eric Dumazet <edumazet@google.com>
Date: 2017-09-26 13:20:32
On Mon, Sep 25, 2017 at 10:52 PM, Wei Wang [off-list ref] wrote:
On Mon, Sep 25, 2017 at 7:23 PM, Eric Dumazet [off-list ref] wrote:quoted
On Mon, Sep 25, 2017 at 7:07 PM, Martin KaFai Lau [off-list ref] wrote:quoted
I am probably still missing something. Considering the del operation should be under the writer lock, if rt->rt6i_node should be NULL (for rt that has already been removed from fib6), why this WARN_ON() is triggered? An example may help.Look at the stack trace, you'll find the answers... ip6_link_failure() -> ip6_del_rt() Note that rt might have been deleted from the _tree_ already.Had a brief talk with Martin. He has a valid point. The current WARN_ON() code is as follows: #if RT6_DEBUG >= 2 if (rt->dst.obsolete > 0) { WARN_ON(fn); return -ENOENT; } #endif The WARN_ON() only triggers when fn is not NULL. (I missed it before.) In theory, fib6_del() calls fib6_del_route() which should set rt->rt6i_node to NULL and rt->dst.obsolete to DST_OBSOLETE_DEAD within the same write_lock session. If those 2 values are inconsistent, it indicates something is wrong. Will need more time to root cause the issue. Please ignore this patch. Sorry about the confusion.
Oh well, for some reason I was seeing WARN_ON(1) here, since this is a construct I often add in my tests ...