On Thu, 28 Nov 2019, Oliver Neukum wrote: > Hi, > > it is a bit awkward to complain here, as your patch tests as correct > while mine didn't, but this is a race condition. > You can't guarantee that urb->status != 0. > The kill may happen while the completion handler is running for > a successful transfer. > > I really appreciate your help, but I must understand what is going > wrong here. You are stopping the resubmit, but how could the resubmit > ever have not failed? You probably have figured all this out already, but I'll answer anyway. The code I changed doesn't race with the error condition you were concerned about. The two are independent, and it doesn't matter if the kill happens while the completion handler is running. In the case my patch addresses, the resubmit does not fail. Rather, it succeeds but then the URB completes with a -EPROTO error. The problem is that the completion handler then resubmits the URB again, and it completes again with the same error, right away, in a tight loop -- which prevents the CPU from executing any other code. The way to fix the problem is to break the loop by not resubmitting, which is what the patch does. Alan Stern
