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.
Thanks
