On Tue, 11 Oct 2005, Franck wrote:
> 2005/10/11, Alan Stern <[EMAIL PROTECTED]>:
> > Be more careful here. It doesn't hold urb->lock while _reading_
> > urb->status; there's no point. But it does hold urb->lock while
> > _writing_ urb->status. That is necessary.
> >
>
> hmm, sorry but I don't see why it needs a lock while writing but not
> while reading...can you explain please ?
This is true of shared values in general. The purpose of a lock is to let
you do something, knowing that the value won't change while you're doing
it. If all you're doing is reading, then it usually doesn't matter
whether the value changes.
Consider a simple example of reading:
spin_lock(&urb->lock);
if (urb->status == -EINPROGRESS)
printk("URB is in progress\n");
else
printk("URB is not in progress\n");
spni_unlock(urb->lock);
Now imagine what would happen if the code didn't acquire the lock. The
value could be changed by another thread in between the "if" statement's
test and the printk statement. But who cares? The overall effect is
exactly the same as if the other thread had changed the value _after_ the
printk statement executed.
Okay, so consider an example of writing:
spin_lock(&urb->lock);
if (urb->status == -EINPROGRESS)
urb->status = 0;
spin_unlock(&urb->lock);
Now imagine what could happen if the code didn't acquire the lock.
Another thread could unlink the URB, changing urb->status to -ENOENT, in
between the "if" statement's test and the assignment statement. This
would mean the code would do something very wrong: It would set the
unlinked URB's status to 0.
> Another point in my hcd is that an urb can already be transfered by hw
> before hcd->urb_enqueue method is called. Actually as soon as this urb
> is linked into the corresponding ep's urb list, the hw can send it. Do
> you think it can be an issue ?
Yes. Your code does not own the ep's list, usbcore does. Your HCD should
not even be aware of an URB until urb_enqueue is called. You need to
maintain your own lists, using the urb->hcpriv private data structure.
What would happen if your urb_enqueue method had to reject the submission
because it couldn't allocate memory for the private data structure? The
hardware might already be transferring the rejected URB!
> I'm asking this question because I get sometime a warning on the
> console saying:
> "Badness in kref_get at lib/kref.c:32".
Without knowing more about the context, I can't say what that error
message is related to.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
