> But you are right, the driver must not make any assumption about the state
> of an urb if it escaped the blocking due to pending signal. IMHO it's the
> drivers job to manage the state of all its urb's appropiately - pending
> for completion or not. I don't see what's wrong if the driver looks at
> urb->status at the next read(2) or whenever needed to find out whether it
> is still EINPROGRESS or not. If not, it was apparently completed at some
> time in the past (don't care when - it's ready now). If not ready, we
> block again or timeout. fop->release (i.e. close(2)) is a different story
> of course.
I took a close look at usblp_write.
If a signal is received while an urb is in flight, the returned count is
incorrect. On the next syscall the data transfered by that urb is counted for
the writecount.
The problem with that is that the buffer might have changed in the meantime.
There's not much sense in doing this, but it is a bug.
I conclude that you need to unlink the urb in flight before returning
prematurely to run a signal handler.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
