> From: Michael Kelley (EOSG) > Sent: Thursday, May 31, 2018 09:41 > > > > IMO we can disable the per-channel tasklet to exclude the race: > > This way, when we exit the loop, we're sure hv_pci_onchannelcallback() can > > not run anymore. What do you think of this? > > I've stared at this and the tasklet code over a couple of days now. Adding the > call to tasklet_disable() solves the immediate problem of preventing > hv_pci_onchannelcallback() from calling complete() against a completion > packet > that has been popped off the stack. But in doing so, it simply pushes the core > problem further down the road and leaves it unresolved. > > tasklet_disable() does not prevent the tasklet from being scheduled. So if > there > is a response from Hyper-V to the original message, the tasklet still gets > scheduled. Because it is disabled, it will sit in the tasklet queue and be > skipped > over each time the queue is processed. Later, when the channel is > eventually > deleted in free_channel(), tasklet_kill() is called. Unfortunately, tasklet_kill() > will get stuck in an infinite loop, waiting for the tasklet to run. There aren't > any tasklet interfaces to dequeue an already scheduled tasklet. I think you're correct. > Please double-check my reasoning. To solve this problem, I think the VMbus > driver code will need some additional synchronization between rescind > notifications and a response, which may or may not have been sent, and > which could be processed after the rescind. I haven't yet thought about > what this synchronization might need to look like. > > Michael Yes, it looks the VMBus driver needs to provide an API to cope with this. I'll try to further investigate the issue. -- Dexuan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
