On Thu, 28 Nov 2019, Oliver Neukum wrote: > Am Mittwoch, den 27.11.2019, 16:11 -0500 schrieb Alan Stern: > > Oliver: > > > > Make of this what you will... > > Hi, > > first, thank you. Second, this is teaching me to question my > assumptions. There is no disconnect at all. We are busy looping > in the error handler as we have virtual hardware in this test, > which can execute an URB without waiting for hardware. > > So should we kill error handling for this case? Okay. First of all, we must recognize that these syzbot tests have encountered two separate bugs. The first is the one fixed in your original patches (the use-after-free). This bug needs no discussion; it looks like your patch fixes it. The second bug is the CPU starvation caused by the tight resubmit loop in the completion handler. It is the reason why you kept getting failure reports back from syzbot. It is to some extent a misleading result, related to the fact that dummy-hcd doesn't use real hardware, as you noted. Nevertheless, the fix I posted is appropriate. I posed this question to Greg KH some weeks ago, and he pointed out that after some discussion on the mailing list, people had generally agreed that drivers should not blindly resubmit URBs when they get an unrecognized error status. In this situation, error recovery has to occur at a higher level (for example, the user could unplug the device and then plug it in again). So even though with real hardware this tight resubmit loop might not end up using all the available CPU time, not resubmitting is still the right approach. Alan Stern
