[dpdk-stable] patch 'vhost: fix device cleanup at stop' has been queued to LTS release 16.11.7

[Luca Boccassi]

On Wed, 2018-05-23 at 10:20 +0100, Luca Boccassi wrote:
> On Wed, 2018-05-23 at 09:35 +0200, Maxime Coquelin wrote:
> > Hi Luca, Tomasz,
> > 
> > While testing 16.11 branch, I noticed vhost lib is broken.
> > The symptoms is no packets are sent or received.
> > 
> > I ran a bisect which points to this commit. Reverting it solves the
> > issue.
> > 
> > Debugging a bit more, I can see that the callfd is valid when no
> > packets
> > are being transmitted. I think the problem is that the callfd is
> > received after the kickfd:
> > 
> > VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK
> > VHOST_CONFIG: vring kick idx:0 file:16
> > VHOST_CONFIG: virtio is not ready for processing.
> > VHOST_CONFIG: read message VHOST_USER_SET_VRING_CALL
> > VHOST_CONFIG: vring call idx:0 file:17
> > 
> > And in 16.11, the new_device callback is called from the
> > VHOST_USER_SET_VRING_KICK handling, only if the device is ready.
> > This is different in later versions, where the new_device callback
> > can be called for any request.
> > 
> > The right way to fix this would be to move the new_device callback
> > call
> > for any request, but I think there is a non-negligible risk of
> > regression so we'd need to be careful doing that.
> > 
> > Other option is to simply revert Tomasz patch in 16.11 LTS. This is
> > not
> > ideal because Tomasz patch is fixing a real issue (new_device get
> > called
> > with an outdated/invalid callfd). However, I don't know if it has
> > real
> > consequences, as the callfd is updated right after.
> > 
> > Except if someone face real issue due to callfd being updated after
> > new_device is called, then my suggestion would be to revert Tomasz
> > patch
> > as we are at 6 months of 16.11 EOL.
> > 
> > Luca, Tomasz, what's your take on this?
> > 
> > Regards,
> > Maxime
> 
> I'm fine with your suggestion of reverting the patch, as it seems
> less
> risky.

I also can easily confirm the regression - given no objection from
Tomasz, I'll revert.

-- 
Kind regards,
Luca Boccassi