Bug 8212 - Race: a lock is expected before calling gs_free_ports, but it is not held in some case and it is held in other cases
Summary: Race: a lock is expected before calling gs_free_ports, but it is not held in ...
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Greg Kroah-Hartman
Depends on:
Blocks: USB
  Show dependency tree
Reported: 2007-03-15 19:32 UTC by Lin Tan
Modified: 2007-09-05 06:46 UTC (History)
0 users

See Also:
Kernel Version:
Tree: Mainline
Regression: ---


Description Lin Tan 2007-03-15 19:32:34 UTC
Block comment before function gs_free_ports() says "The device lock is normally
held when calling this function."

But in the following call chains, NO lock is acquired:
gs_free_ports	<- gs_unbind	<- gs_bind

In some others such as:
gs_free_ports	 <- gs_disconnect
a lock IS held.
Comment 1 Lin Tan 2007-03-16 16:14:07 UTC
I found this bug using a static checking tool.
Comment 2 Matthias Kaehlcke 2007-04-14 04:56:20 UTC
gs_bind() and gs_unbind() are called on module load/unload respectivly. i think
the code assumes that the module won't be loaded/unloaded/used simultaneously.
i'm a newbie but i suppose the kernel assures that the module can't be used or
unloaded until it is completely loaded, and the same way that it can't be
unloaded (or reloaded) while it used by a device. 
Comment 3 Greg Kroah-Hartman 2007-09-05 06:46:48 UTC
Yes, a module can not be unloaded at the same time, so this all should just be fine.

Note You need to log in before you can comment on or make changes to this bug.