Am Freitag, 30. März 2007 09:48 schrieb Greg KH:
> > As an added complication, the resubmission would happen on another cpu.
> > Therefore the order on the bus must be correct, hence the "smp_mb()".
>
> This part I still don't understand.
>
> What are we doing a memory barier for after the completion handler is
> finished here? If we set the write_urb_busy flag to 0 after we check
> the status, we should be safe, as that urb will not be able to be
> resubmitted until that point in time. Or should we be grabbing the lock
> for the port when we change the status instead? That would make more
> sense I think.
CPU A (handler) CPU B (write path)
a = urb->status if (!write_busy)
write_busy = 0 usb_submit_urb(urb)
On the bus CPU A's memory references can be reordered into:
CPU A
write_busy = 0
a = urb->status
The urb may be resubmitted on _another_ CPU which is executing the
write code path. It may resubmit as soon as it sees the flag as zero on
the bus. We must not assume that CPUs do on the bus as they do in the
code. Without explicit instructions a CPU is free to postpone a read after
a write. Therefore the correct sequence is:
CPU A
a = urb->status
smp_mb()
write_busy = 0
To solve this with locking would require both CPU A and CPU B to take
the lock, which means that the urb would have to be submitted with
GFP_ATOMIC.
Regards
Oliver
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
