Kernel Bug Tracker – 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
Last modified: 2007-09-05 06:46:48 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.
I found this bug using a static checking tool.
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.
Yes, a module can not be unloaded at the same time, so this all should just be fine.