Hi,
while trying to get the pl2303 driver running with my ATEN UC-232A serial
converter (*), I'm wondering whether there might be a certain kind
of race condition present in the usb serial code.
[ (*) For a patch against 2.4.10, which adds yet some additional features,
see http://www.baty.hanse.de/pl2303/pl2303-2.4.10.diff.
The patch has some overlap with current 2.4.11/2.4.12 changes,
thus it unfortunately won't apply cleany against current 2.4.12 yet. ]
The data of the struct urb will be modified by the usb core -- possibly from
interrupt context -- after the urb is submitted by means of usb_submit_urb().
Thus, when an urb is submitted, it may not be touched until the transfer
is completed. That means that after urb submission, only the completion handler
should access the urb data at first (and may optionally authorize other
code to access the urb data afterwards).
Now, usbserial.c::generic_write() contains some code like
if (urb->status == -EINPROGRESS) {
dbg (__FUNCTION__ " - already writing");
return (0);
}
:
FILL_BULK_URB(urb)
:
usb_submit_urb(urb).
which is not serialized against the usb core's interrupt handlers. Those
irq handlers might simultaneously modify data inside the urb structure.
The only method to enforce such serialization seems to globally
turn irq off which is neither very SMP friendly nor done anyway
inside the usb serial code.
Well, in the special case of generic_write, this race is likely to result
in false-positive `in-progress' indications only. The driver will
recover from this because the upper layers will re-try after
generic_write() has returned 0.
However, on SMP, the situation is worse: If interrupt handler modifies
urb data, and if irq handler and generic_write run on a different CPUs,
scenarios are imaginable where generic_write() modifies and re-submits
the urb before the interrupt handler (inlucuding the urb completion
handler) has finished.
Several serial drivers use the generic_write() method or code
derived therefrom. Thus, they might be subject to the same problem.
With the pl2303 driver, the situation is even worse, because
pl2303_write_bulk_callback() might re-transmit the urb on its own for
error recovery. Thus, with pl2303, races might already cause harm on a
single processor machine.
Henner
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
