lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 12 May 2007 08:13:56 -0400
From:	Kyle Moffett <>
To:	Ben Greear <>
Cc:, LKML Kernel <>,
	Stephen Hemminger <>,
	OSDL Linux Bridging <>
Subject: Re: [BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel

On May 11, 2007, at 01:49:27, Kyle Moffett wrote:
> On May 10, 2007, at 00:34:11, Kyle Moffett wrote:
>> On May 10, 2007, at 00:25:54, Ben Greear wrote:
>>> Looks like a deadlock in the vlan code.  Any chance you can run  
>>> this test with lockdep enabled?
>>> You could also add a printk in vlan_device_event() to check which  
>>> event it is hanging on, and the netdevice that is passed in.
>> Ok, I'll try building a 2.6.21 kernel with lockdep and some  
>> debugging printk()s in the vlan_device_event() function and get  
>> back to you tomorrow.  Thanks for the quick response!


> ifup -a brings up the interfaces in this order (See previous email  
> for configuration details):
> lo net0 wfi0 world0 lan lan:0 world
> ifdown -a appears to bring them down in the same order (at least,  
> until it gets stuck).

Hmm, turns out that it always hung downing this entry in my  
interfaces file, independent of ordering:

iface world0 inet manual
	mac-address 8b:8d:cb:91:e2:4c
	minimally-up yes
	vlan-dev net0
	vlan-id 4094

By commenting out the MAC address line it worked.  Yes, I realize the  
MAC address specified there is bogus, I managed to {think,type}o that  
one somehow.  I had been intending to specify a locally-allocated  
virtual MAC address on world0 but instead I managed to somehow assign  
one with the MAC multicast bit set (01:00:00:00:00:00)
If I change the above garbage MAC to 02:00:00:00:00:01 (first 02 is  
the locally-administrated bit) then it seems to work perfectly fine,   
My guess that the bridging code doesn't properly drop all references  
to world0 when it has that garbage MAC address on it (since the  
problem only shows up when both the invalid mac-address is present  
*AND* I start the "world" bridge).  I suppose this isn't really a big  
problem, but it would be nice if things didn't leak refcounts on  
invalid input.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists