[lkml]   [2018]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared
> 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

 \ /
  Last update: 2018-05-31 23:01    [W:0.043 / U:3.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site