> 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. > >> 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. > > Alan Stern > > -- > 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 > Hi Alen, if we add check for ehci->reclaim->qh_state == QH_STATE_UNLINK in ehci_irq() and ehci_iaa_watchdog() i still see a race : what if end_unlink_async for QH1 called start_unlink_async(QH2) and IAAD interrupt fired after QH2->qh_state is set to QH_STATE_UNLINK. Thanks, Hemant -- 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
