RE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

[Dexuan Cui]

> 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