2.6.10 ipv6/8021q lockup on vconfig on interface removal

2.6.10 ipv6/8021q lockup on vconfig on interface removal

[Andre Tomt]

I sent this initially about a week ago, but nobody have said anything, 
not even a confirmation that its beeing looked into, or about me beeing 
silly - highly unusual on netdev! So I'm reposting (with slight 
modifications), boo, shame on me. Just a bit worried it slipped through 
the cracks.



Hi!

Another "unregister_netdevice: waiting for eth0.1 to become free. Usage
count = 1" issue coming up.. Fun fun fun! And this one also seems to be
related to the ipv6 stack.

I can reproduce this reliably this by ifdown lo before ifdown'ing
eth0.1. That is, if lo goes down first, vconfig rem eth0.1 gets stuck
when run later. This only happens with ipv6.ko loaded. I havn't added
*any* ipv6 adresses to any interace, the only one are those the
ipv6-stack adds itself.

This is hitting us often on our routers, as we have ipv6.ko loaded, and
Debian runs ifdown -a (bring down all configured interfaces, starting
with lo unfortunatly) on shutdown and reboot. I've currently 
workarounded the problem by making sure ifdown -a is not run on reboot 
or shutdown, but this is, well, a workaround.

Bringing down non-vlan interfaces works just fine after killing lo. I 
have not attempted to *remove* them like vconfig does, though.

a backtrace from vconfing captured with sysrq-T (quickly typed off-screen):

shedule_timeout
process_timeout
netdev_wait_allrefs
netdev_wait_allrefs
netdev_run_todo
unregister_vlan_device [8021q]
vlan_ioctl_handler [8021q]
sock_ioctl
sys_ioctl
syscall_call

The lab machine is running with a minimalist config, no listeners
besides sshd, ipv6.ko and 8021q.ko loaded.

Re: 2.6.10 ipv6/8021q lockup on vconfig on interface removal

[Ben Greear]

Andre Tomt wrote:
> I sent this initially about a week ago, but nobody have said anything, 
> not even a confirmation that its beeing looked into, or about me beeing 
> silly - highly unusual on netdev! So I'm reposting (with slight 
> modifications), boo, shame on me. Just a bit worried it slipped through 
> the cracks.

My take on this is that it is a bug in the IPv6 code.  If the IPv6 people
think that the VLAN code might could be causing this, then I am open to
suggestions as to how the VLAN code might be in error....

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: 2.6.10 ipv6/8021q lockup on vconfig on interface removal

[Hasso Tepper]

Ben Greear wrote:
> Andre Tomt wrote:
> > I sent this initially about a week ago, but nobody have said anything,
> > not even a confirmation that its beeing looked into, or about me beeing
> > silly - highly unusual on netdev! So I'm reposting (with slight
> > modifications), boo, shame on me. Just a bit worried it slipped through
> > the cracks.
>
> My take on this is that it is a bug in the IPv6 code.  If the IPv6 people
> think that the VLAN code might could be causing this, then I am open to
> suggestions as to how the VLAN code might be in error....

There were similar problems with tunnels in 2.6.8 and 2.6.9 kernels. They 
seems to be gone now in 2.6.10.

Does it help, Andre?


-- 
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

Re: 2.6.10 ipv6/8021q lockup on vconfig on interface removal

[Andre Tomt]

Hasso Tepper wrote:
> Ben Greear wrote:
> 
>>Andre Tomt wrote:
>>
>>>I sent this initially about a week ago, but nobody have said anything,
>>>not even a confirmation that its beeing looked into, or about me beeing
>>>silly - highly unusual on netdev! So I'm reposting (with slight
>>>modifications), boo, shame on me. Just a bit worried it slipped through
>>>the cracks.
>>
>>My take on this is that it is a bug in the IPv6 code.  If the IPv6 people
>>think that the VLAN code might could be causing this, then I am open to
>>suggestions as to how the VLAN code might be in error....
> 
> 
> There were similar problems with tunnels in 2.6.8 and 2.6.9 kernels. They 
> seems to be gone now in 2.6.10.
> 
> Does it help, Andre?

As said in the subject, 2.6.10 exibits this. I had a similar issue 
earlier on in 2.6.8, that one got fixed with a host of other related 
ones. Then the same symptoms popped up sometime later in the development 
of the kernel; not sure exactly when this got introduced as we only ran 
our own internal 2.6.8 tree with the fix in.

I should probably do a binary search and at least pinpoint when it 
happened, but I won't have any free resources to do so until sometime 
this weekend.