Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
>
>
> 在 2021/5/27 下午1:08, Yongji Xie 写道:
> > On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
> >>
> >> 在 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 写道:
> >>>>> +
> >>>>> +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);
> >>>> What happens if the userspace(malicous) doesn't give a response forever?
> >>>>
> >>>> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>>>
> >>> How about using wait_event_killable_timeout() instead?
> >>
> >> Probably, and then we need choose a suitable timeout and more important,
> >> need to report the failure to virtio.
> >>
> > Makes sense to me. But it looks like some
> > 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?
>
>
> Maybe, but I'm not sure how hard we can do that.
>

We need to change all virtio device drivers in this way.

> We had NEEDS_RESET but it looks we don't implement it.
>

Could it handle the failure of get_feature() and get/set_config()?

> Or a rough idea is that maybe need some relaxing to be coupled loosely
> with userspace. E.g the device (control path) is implemented in the
> kernel but the datapath is implemented in the userspace like TUN/TAP.
>

I think it can work for most cases. One problem is that the set_config
might change the behavior of the data path at runtime, e.g.
virtnet_set_mac_address() in the virtio-net driver and
cache_type_store() in the virtio-blk driver. Not sure if this path is
able to return before the datapath is aware of this change.

Thanks,
Yongji




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux