linux-kernel - Re: commit 554f76962d3a6eb5110415f1591aca83f96a84ae hangs USB for vmware 7.0.1

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] [day] [month] [year] [list]

Date:	Fri, 05 Mar 2010 19:45:36 -0800
From:	Petr Vandrovec <petr@...are.com>
To:	Jeff Chua <jeff.tw.chua@...il.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Oliver Neukum <oliver@...kum.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: commit 554f76962d3a6eb5110415f1591aca83f96a84ae hangs USB for
 vmware 7.0.1

Linus Torvalds wrote:
> 
> On Sat, 6 Mar 2010, Jeff Chua wrote:
>> Linux version v2.6.33-5399-gcc7889f with reiser3 and vmware-7.0.1
>>
>> Starting vmware just hang even before displaying the main GUI. Reverting
>> 554f76962d3a6eb5110415f1591aca83f96a84ae solves the problem.
>>
>> It seems vmware is trying to access the USB but this commit blocks it.
>>
>> So, is this a vmware problem or shall this be reverted?

Hello,
    does your box hang, or is it just vmware process that is hung?  I've 
noticed that my box here at work has this change too, and I do not see 
any hang - neither in kernel, or in GUI startup, nor in test sample:

open("/proc/bus/usb/devices", O_RDWR)   = 3
poll([{fd=3, events=POLLIN}], 1, 5000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 5000)  = 0 (Timeout)
exit_group(0)                           = ?
petr-dev3:/tmp# uname -a
Linux petr-dev3 2.6.33-64-05079-g6517b45-dirty #51 SMP PREEMPT Thu Mar 4 
20:29:55 PST 2010 x86_64 GNU/Linux

							Petr

[Removed Eli from CC.  He left.]

> 
> It's almost certainly a deadlock through some path that wasn't tested.
> 
> Can you enable lockdep on that kernel when you run vmware, which should 
> give us a nice callchain etc, and hopefully make it very obvious what goes 
> on.
> 
> Reverting it is obviously an option, but with some more info maybe there's 
> a better solution.
> 
> (It may be that the deadlock is obvious to Oliver/Greg even without any 
> lockdep chains, of course, but still worth trying, I suspect)
> 
> 		Linus

--
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/