On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
Makes sense to me. But it looks like some
在 2021/5/27 下午12:57, Yongji Xie 写道:
On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
在 2021/5/17 下午5:55, Xie Yongji 写道:How about using wait_event_killable_timeout() instead?
+What happens if the userspace(malicous) doesn't give a response forever?
+static int vduse_dev_msg_sync(struct vduse_dev *dev,
+ struct vduse_dev_msg *msg)
+{
+ init_waitqueue_head(&msg->waitq);
+ spin_lock(&dev->msg_lock);
+ vduse_enqueue_msg(&dev->send_list, msg);
+ wake_up(&dev->waitq);
+ spin_unlock(&dev->msg_lock);
+ wait_event_killable(msg->waitq, msg->completed);
It looks like a DOS. If yes, we need to consider a way to fix that.
Probably, and then we need choose a suitable timeout and more important,
need to report the failure to virtio.
vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
return value. Now I add a WARN_ON() for the failure. Do you mean we
need to add some change for virtio core to handle the failure?
Thanks,
Yongji