On 9/12/2012 6:29 PM, Alan Stern wrote: > On Wed, 12 Sep 2012, Pavan Kondeti wrote: > >> Thanks for your response. I and Hemant work together. We are thinking a >> scenario where this NULL dereference could happen. Please let us know if >> our understanding is correct or not. we are assuming that async doorbell >> interrupt can not be stopped by software as mentioned at >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6feff1b92bedab133c5835e510d11f62e843b257 > > ... > > Your analysis looks right. Good work. By the way, if the IAA > interrupt doesn't fire within 10 ms of the IAA doorbell, your EHCI > controller has a serious design flaw. > Thanks. I have seen watchdog timer getting expired occasionally in my testing. I will check this with our hardware designers. Another possibility could be CPU being in idle (C) state when controller generates IAAD interrupt. I will check this. >> If at all the above scenario is possible, we have to fix the race >> between watchdog timer function and IAAD interrupt handler. In other >> words, we should not call end_unlink_async() prematurely. can we simply >> return from end_unlink_async if QH state != QH_STATE_UNLINK to avoid >> this scenario? > > It would be better to change ehci_iaa_watchdog() and ehci_irq(). > Where they test that ehci->reclaim is non-NULL, they should also test > that ehci->reclaim->qh_state == QH_STATE_UNLINK. That way the driver > doesn't end up doing a bunch of extra work and incrementing the > statistics counter incorrectly. > Agreed. Thanks, Pavan -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
