Thread (8 messages) flat view 8 messages, 3 authors, 2017-09-27

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 ...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help