On Wed, Jul 14, 2021 at 02:02:50PM +0800, Jason Wang wrote:
>
> 在 2021/7/14 下午1:54, Michael S. Tsirkin 写道:
> > On Wed, Jul 14, 2021 at 01:45:39PM +0800, Jason Wang wrote:
> > > > +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> > > > + struct vduse_dev_msg *msg)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + init_waitqueue_head(&msg->waitq);
> > > > + spin_lock(&dev->msg_lock);
> > > > + msg->req.request_id = dev->msg_unique++;
> > > > + vduse_enqueue_msg(&dev->send_list, msg);
> > > > + wake_up(&dev->waitq);
> > > > + spin_unlock(&dev->msg_lock);
> > > > +
> > > > + wait_event_killable_timeout(msg->waitq, msg->completed,
> > > > + VDUSE_REQUEST_TIMEOUT * HZ);
> > > > + spin_lock(&dev->msg_lock);
> > > > + if (!msg->completed) {
> > > > + list_del(&msg->list);
> > > > + msg->resp.result = VDUSE_REQ_RESULT_FAILED;
> > > > + }
> > > > + ret = (msg->resp.result == VDUSE_REQ_RESULT_OK) ? 0 : -EIO;
> > >
> > > I think we should mark the device as malfunction when there is a timeout and
> > > forbid any userspace operations except for the destroy aftwards for safety.
> > This looks like if one tried to run gdb on the program the behaviour
> > will change completely because kernel wants it to respond within
> > specific time. Looks like a receipe for heisenbugs.
> >
> > Let's not build interfaces with arbitrary timeouts like that.
> > Interruptible wait exists for this very reason.
>
>
> The problem is. Do we want userspace program like modprobe to be stuck for
> indefinite time and expect the administrator to kill that?
Why would modprobe be stuck for forever?
Is this on the module probe path?
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
