linux-kernel - Re: [BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <EE6715FC-176D-4DA3-A0B3-6BDCC16122A6@mac.com>
Date:	Thu, 10 May 2007 00:34:11 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	netdev@...r.kernel.org, LKML Kernel <linux-kernel@...r.kernel.org>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	OSDL Linux Bridging <bridge@...l.org>
Subject: Re: [BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel

On May 10, 2007, at 00:25:54, Ben Greear wrote:
> Kyle Moffett wrote:
>> vconfig       D 83CCD8CE     0 16564  16562                      
>> (NOTLB)
>>        efdd7e7c 00000086 ee120afb 83ccd8ce 98f00788 b7083ffa  
>> 5384b49a c76c0b05
>>        9ebaf791 00000004 efdd7e4e 00000007 f1468a90 2ab74174  
>> 00000362 00000326
>>        f1468b9c c180e420 00000001 00000286 c012933c efdd7e8c  
>> df98a000 c180e468
>> Call Trace:
>> [<c012933c>] lock_timer_base+0x15/0x2f
>> [<c0129445>] __mod_timer+0x91/0x9b
>> [<c02988f5>] schedule_timeout+0x70/0x8d
>> [<f8b75209>] vlan_device_event+0x13/0xf8 [8021q]
>
> 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!

> Since the vlan code holds RTNL at this point, then most other  
> network tasks will eventually hang as well.

Well, it's less of an "eventually" and more of an "almost  
immediately".  When that happens pretty close to everything more  
complicated than socket(), bind(), and connect() with straightforward  
UNIX or INET sockets tends to stick completely.

Thanks again!

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/