On Wed, 25 Jun 2003, Tuukka Toivonen wrote:
> Alan Stern wrote:
> >Look at usb-skeleton.c. Exactly this problem was corrected there by
> >adding a static lock a couple of months ago.
>
> Thanks for the tip. Although my intention was not to ask how to fix the
> bug, but point out that ov511.c appears to be buggy. If people agree, I can
> try fixing it.
Actually I meant to say usb-skeleton in 2.5. The version in 2.4.21 still
has that same bug. If you want to fix ov511.c you could use the same
approach as the 2.5 version.
> A simple question about usb-skeleton.c (kernel 2.4.21):
> - Is there a particular reason that the mutex at skel_disconnect:645 is
> unlocked before freeing the memory:
> if (!dev->open_count) {
> up (&dev->sem); <- 645
> skel_delete (dev);
> } else {
> I don't see any reason, the mutex is being destroyed anyway.
> It would be safer to not unlock the mutex, if there is somebody
> waiting for it, it is a bug, but it would hang indefinitely
> instead of corrupting random memory if the mutex were not unlocked.
Some programmers have a strong sense of symmetry; if a mutex was acquired
they want to release it again, even if it's just going to be destroyed.
Also there are software analysis tools that count the number of ups and
downs on each semaphore to warn about mismatches; unlocking prevents the
tools from complaining.
If there is somebody still waiting for the mutex when it's destroyed then
the driver has a bug. In that case it doesn't matter whether you do a
final up() or not; the bug needs to be fixed.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
