neigh_params_release() usage in net/ipv6/addrconf.c

neigh_params_release() usage in net/ipv6/addrconf.c

[Chase Douglas]

I'm debugging an issue I'm seeing when I use vlan with IPv6 support.  
After bringing up the device, I'm unable to bring it down and  
unregister it. I put some debug statements around dev_hold() and  
dev_put() to see what was going on:

dev_hold() called on lo.2, new refcnt: 1 (net/core/dev.c:4162)
dev_hold() called on lo.2, new refcnt: 2 (net/core/neighbour.c:1357)
dev_hold() called on lo.2, new refcnt: 3 (net/ipv4/devinet.c:178)
dev_hold() called on lo.2, new refcnt: 4 (net/core/neighbour.c:1357)
dev_hold() called on lo.2, new refcnt: 5 (net/8021q/vlan.c:266)
dev_hold() called on lo.2, new refcnt: 6 (net/core/link_watch.c:219)
dev_put()  called on lo.2, new refcnt: 5 (net/core/link_watch.c:191)
dev_hold() called on lo.2, new refcnt: 6 (net/core/dev.c:684)
dev_put()  called on lo.2, new refcnt: 5 (net/ipv4/fib_semantics.c:149)
dev_hold() called on lo.2, new refcnt: 6 (net/core/dev.c:684)
dev_hold() called on lo.2, new refcnt: 7 (net/ipv4/fib_frontend.c:173)
dev_put()  called on lo.2, new refcnt: 6 (net/ipv4/route.c:2453)
dev_put()  called on lo.2, new refcnt: 5 (net/ipv4/fib_semantics.c:149)
dev_put()  called on lo.2, new refcnt: 4 (net/core/neighbour.c:1393)
dev_put()  called on lo.2, new refcnt: 3 (net/ipv4/devinet.c:151)
dev_put()  called on lo.2, new refcnt: 2 (net/core/dev.c:4010)
dev_put()  called on lo.2, new refcnt: 1 (net/8021q/vlan.c:182)
unregister_netdevice: waiting for lo.2 to become free. Usage count = 2

The fourth dev_hold() is in neigh_parms_alloc(), called by  
ipv6_add_dev(). The only place I see neigh_parms_release() called in  
addrconf.c is if ipv6_add_dev() fails later on, or when taking the  
device down in addrconf_ifdown(). Unfortunately, when I bring the vlan  
dev down I never see addrconf_ifdown() called with the how parameter  
set to 1, which is the only instance where neigh_parms_release() would  
be called.

Why is neigh_parms_release() called in addrconf_ifdown() instead of  
in6_dev_finish_destroy(), which looks to me to be the complement of  
ipv6_add_dev()? If neigh_parms_release() really should be called in  
addrconf_ifdown(), does anyone know why it's not being called properly  
in this instance?

PS: I am running my tests using a slightly modified SLES 11 kernel. I  
haven't been able to find anything in the git trees that would  
indicate to me that the problem has been fixed upstream.

Re: neigh_params_release() usage in net/ipv6/addrconf.c

[Jarek Poplawski]

Chase Douglas wrote, On 05/15/2009 06:33 PM:

> I'm debugging an issue I'm seeing when I use vlan with IPv6 support.  
> After bringing up the device, I'm unable to bring it down and  
> unregister it. I put some debug statements around dev_hold() and  
> dev_put() to see what was going on:
> 
> dev_hold() called on lo.2, new refcnt: 1 (net/core/dev.c:4162)
> dev_hold() called on lo.2, new refcnt: 2 (net/core/neighbour.c:1357)
> dev_hold() called on lo.2, new refcnt: 3 (net/ipv4/devinet.c:178)
> dev_hold() called on lo.2, new refcnt: 4 (net/core/neighbour.c:1357)
> dev_hold() called on lo.2, new refcnt: 5 (net/8021q/vlan.c:266)
> dev_hold() called on lo.2, new refcnt: 6 (net/core/link_watch.c:219)
> dev_put()  called on lo.2, new refcnt: 5 (net/core/link_watch.c:191)
> dev_hold() called on lo.2, new refcnt: 6 (net/core/dev.c:684)
> dev_put()  called on lo.2, new refcnt: 5 (net/ipv4/fib_semantics.c:149)
> dev_hold() called on lo.2, new refcnt: 6 (net/core/dev.c:684)
> dev_hold() called on lo.2, new refcnt: 7 (net/ipv4/fib_frontend.c:173)
> dev_put()  called on lo.2, new refcnt: 6 (net/ipv4/route.c:2453)
> dev_put()  called on lo.2, new refcnt: 5 (net/ipv4/fib_semantics.c:149)
> dev_put()  called on lo.2, new refcnt: 4 (net/core/neighbour.c:1393)
> dev_put()  called on lo.2, new refcnt: 3 (net/ipv4/devinet.c:151)
> dev_put()  called on lo.2, new refcnt: 2 (net/core/dev.c:4010)
> dev_put()  called on lo.2, new refcnt: 1 (net/8021q/vlan.c:182)
> unregister_netdevice: waiting for lo.2 to become free. Usage count = 2
> 
> The fourth dev_hold() is in neigh_parms_alloc(), called by  
> ipv6_add_dev(). The only place I see neigh_parms_release() called in  
> addrconf.c is if ipv6_add_dev() fails later on, or when taking the  
> device down in addrconf_ifdown(). Unfortunately, when I bring the vlan  
> dev down I never see addrconf_ifdown() called with the how parameter  
> set to 1, which is the only instance where neigh_parms_release() would  
> be called.

You write about ipv6, but the log is ipv4 only or I miss something.
Anyway, it seems you do this vlan on the loopback. If so, there is:

         if ((dev->flags & IFF_LOOPBACK) && how == 1)
                 how = 0;

at least before 2.6.29 kernels, and vlans copy most of the flags.
Otherwise, how == 1 should work OK.

> PS: I am running my tests using a slightly modified SLES 11 kernel. I  

Generally, it's better to give the kernel number, because everybody
uses Debian here. ...Not! ;-)

Jarek P.

Re: neigh_params_release() usage in net/ipv6/addrconf.c

[Chase Douglas]

On May 16, 2009, at 6:15 PM, Jarek Poplawski wrote:
> Chase Douglas wrote, On 05/15/2009 06:33 PM:
>
>> I'm debugging an issue I'm seeing when I use vlan with IPv6 support.
>> After bringing up the device, I'm unable to bring it down and
>> unregister it. I put some debug statements around dev_hold() and
>> dev_put() to see what was going on:
>>
>> dev_hold() called on lo.2, new refcnt: 1 (net/core/dev.c:4162)
>> dev_hold() called on lo.2, new refcnt: 2 (net/core/neighbour.c:1357)
>> dev_hold() called on lo.2, new refcnt: 3 (net/ipv4/devinet.c:178)
>> dev_hold() called on lo.2, new refcnt: 4 (net/core/neighbour.c:1357)
>> dev_hold() called on lo.2, new refcnt: 5 (net/8021q/vlan.c:266)
>> dev_hold() called on lo.2, new refcnt: 6 (net/core/link_watch.c:219)
>> dev_put()  called on lo.2, new refcnt: 5 (net/core/link_watch.c:191)
>> dev_hold() called on lo.2, new refcnt: 6 (net/core/dev.c:684)
>> dev_put()  called on lo.2, new refcnt: 5 (net/ipv4/fib_semantics.c: 
>> 149)
>> dev_hold() called on lo.2, new refcnt: 6 (net/core/dev.c:684)
>> dev_hold() called on lo.2, new refcnt: 7 (net/ipv4/fib_frontend.c: 
>> 173)
>> dev_put()  called on lo.2, new refcnt: 6 (net/ipv4/route.c:2453)
>> dev_put()  called on lo.2, new refcnt: 5 (net/ipv4/fib_semantics.c: 
>> 149)
>> dev_put()  called on lo.2, new refcnt: 4 (net/core/neighbour.c:1393)
>> dev_put()  called on lo.2, new refcnt: 3 (net/ipv4/devinet.c:151)
>> dev_put()  called on lo.2, new refcnt: 2 (net/core/dev.c:4010)
>> dev_put()  called on lo.2, new refcnt: 1 (net/8021q/vlan.c:182)
>> unregister_netdevice: waiting for lo.2 to become free. Usage count  
>> = 2
>>
>> The fourth dev_hold() is in neigh_parms_alloc(), called by
>> ipv6_add_dev(). The only place I see neigh_parms_release() called in
>> addrconf.c is if ipv6_add_dev() fails later on, or when taking the
>> device down in addrconf_ifdown(). Unfortunately, when I bring the  
>> vlan
>> dev down I never see addrconf_ifdown() called with the how parameter
>> set to 1, which is the only instance where neigh_parms_release()  
>> would
>> be called.
>
> You write about ipv6, but the log is ipv4 only or I miss something.

It doesn't look like there's any ipv6, but I also did a dump_stack()  
each time, and that's how I figured out that ipv6_add_dev() was  
calling neigh_parms_alloc().

> Anyway, it seems you do this vlan on the loopback. If so, there is:
>
>         if ((dev->flags & IFF_LOOPBACK) && how == 1)
>                 how = 0;
>
> at least before 2.6.29 kernels, and vlans copy most of the flags.
> Otherwise, how == 1 should work OK.

I did see that as well. I didn't think that was a fix because I put a  
printk in there to determine if I was hitting it. Unfortunately, I  
forgot to copy the new module over before I retested, so I didn't see  
the message at first. That block was the culprit though.

I grabbed the git commit that included the change to remove the block.  
So far my patched kernel seems to be working correctly with the patch.

>
>> PS: I am running my tests using a slightly modified SLES 11 kernel. I
>
> Generally, it's better to give the kernel number, because everybody
> uses Debian here. ...Not! ;-)

The reason I'm hesitant to do that can be seen in the case of SLES 10  
SP 2. Even though it's 2.6.16, it has so many fixes and backports and  
SuSE changes that it ends up very different from a stock 2.6.16  
kernel. Either way, the SLES 11 kernel is based on 2.6.27.

Thanks for your help!

Re: neigh_params_release() usage in net/ipv6/addrconf.c

[Jarek Poplawski]

On Sat, May 16, 2009 at 06:57:22PM -0400, Chase Douglas wrote:
> On May 16, 2009, at 6:15 PM, Jarek Poplawski wrote:
...
>> Anyway, it seems you do this vlan on the loopback. If so, there is:
>>
>>         if ((dev->flags & IFF_LOOPBACK) && how == 1)
>>                 how = 0;
>>
>> at least before 2.6.29 kernels, and vlans copy most of the flags.
>> Otherwise, how == 1 should work OK.
>
> I did see that as well. I didn't think that was a fix because I put a  
> printk in there to determine if I was hitting it. Unfortunately, I  
> forgot to copy the new module over before I retested, so I didn't see  
> the message at first. That block was the culprit though.
>
> I grabbed the git commit that included the change to remove the block.  
> So far my patched kernel seems to be working correctly with the patch.

This was probably to fix another problem, and considering there is more
such IFF_LOOPBACK tests, doing vlan on the loopback looks risky to me.

> The reason I'm hesitant to do that can be seen in the case of SLES 10 SP 
> 2. Even though it's 2.6.16, it has so many fixes and backports and SuSE 
> changes that it ends up very different from a stock 2.6.16 kernel. Either 
> way, the SLES 11 kernel is based on 2.6.27.

So, you mean SLES 11.1 according to this:
http://distrowatch.com/table.php?distribution=suse

Anyway, it's "expected" here to verify bug reports against possibly
latest stable vanilla kernels, and considering the amount of your
debugging work, I guess it wouldn't add too much.

Cheers,
Jarek P.

Re: neigh_params_release() usage in net/ipv6/addrconf.c

[Jarek Poplawski]

On Sun, May 17, 2009 at 01:09:52PM +0200, Jarek Poplawski wrote:
> On Sat, May 16, 2009 at 06:57:22PM -0400, Chase Douglas wrote:
...
> > way, the SLES 11 kernel is based on 2.6.27.
> 
> So, you mean SLES 11.1 according to this:
> http://distrowatch.com/table.php?distribution=suse

OOPS! So, I should've looked rather here:
http://distrowatch.com/table.php?distribution=novell

Sorry,
Jarek P.