Re: [RFC PATCH V2 3/3] vhost: access vq metadata through kernel virtual address

From: Jason Wang
Date: Sat Dec 29 2018 - 07:42:00 EST

On 2018/12/29 äå3:34, David Miller wrote:
From: Jason Wang <jasowang@xxxxxxxxxx>
Date: Fri, 28 Dec 2018 15:55:37 +0800

+static int vhost_invalidate_vmap(struct vhost_virtqueue *vq,
+ struct vhost_vmap *map,
+ unsigned long uaddr,
+ unsigned long start,
+ unsigned long end,
+ bool blockable)
+ if (start < uaddr && end >= uaddr) {
+ if (!blockable)
+ return -EAGAIN;
+ mutex_lock(&vq->mutex);
+ if (map->addr)
+ vunmap(map->unmap_addr);
+ map->addr = NULL;
+ map->unmap_addr = NULL;
+ mutex_unlock(&vq->mutex);
+ }
+ return 0;
What are the rules for these invalidate operations?

Can there be partial overlaps? If so, wouldn't you need some way of
keeping track of the partially overlapping unmaps so that once all of
the invalidates covering the range occur you properly cleanup and do
the vunmap()?

Yes, there can be partial overlap, so the check is buggy. We will remap the whole range in vq_meta_prefetch() before datapath path try to use them, so there's no need to track partial mapping here.

I spot another bug that the caller will access vq->avail without synchronized with vhost ioctl. Since we don't want to hold vq mutex for each invalidation, I will tear down MMU notifier during vhost ioctl to make sure invalidation request can access them without hold vq mutex.