> From: Wolfgang Mües <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Date: Sat, 3 Nov 2001 21:53:52 +0100
> at release(), the mutex is aquired. Then, the whole descriptor
> is freed...
>
> I have a problem with this design:
You are not alone. I think it is obvious that an object cannot
be locked against removal and destruction with a lock inside it.
This subject was trashed to death when urb->lock was used by
usb-uhci. Georg fixed it since then.
It is possible to make this work, combining in-storage lock
with outside flags, or doing something else in addition to
in-storage lock (see below).
> I have seen this sort of design in usb_skeleton.c and some
> other drivers. Is there something in user or kernel space
> which protects the driver against this race? Is this safe?
Disconnects are handled from khubd context _only_, which
saves us in many questionable cases.
In case of skeleton driver, the play is little different,
because usage counters are involved. They protect us from
doble deletion, and the lock only serves to ensure the
integrity of the counter. The code in 2.4.13 seems to be
a little buggy, that's all. Perhaps this should be done:
--- linux-2.4.13-ac2/drivers/usb/usb-skeleton.c Mon Oct 1 13:45:48 2001
+++ linux-2.4.13-ac2-e/drivers/usb/usb-skeleton.c Sun Nov 4 16:35:06 2001@@
+-604,6 +604,7 @@
/* if the device is not opened, then we clean up right now */
if (!dev->open_count) {
+ up (&dev->sem);
skel_delete (dev);
} else {
dev->udev = NULL;
-- Pete
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
