Olaf Hering <olaf@xxxxxxxxx> writes: > On Thu, Oct 08, Vitaly Kuznetsov wrote: > >> > @@ -295,9 +288,6 @@ static int fcopy_on_msg(void *msg, int len) >> > if (fcopy_transaction.state == HVUTIL_DEVICE_INIT) >> > return fcopy_handle_handshake(*val); >> > >> > - if (fcopy_transaction.state != HVUTIL_USERSPACE_REQ) >> > - return -EINVAL; >> > - >> >> This particular change seems unrelated and I'm unsure it's safe to >> remove this check. It is meant to protect against daemon screwing the >> protocol and writing to the device when it wasn't requested for an >> action. It is correct to propagate -EINVAL in this case. Or am I missing >> something and the check is redundant now? > > What can happen if there is an odd write request? I think we don't want to propagate misbehaving daemon's data to the host -- let's cut it here. E.g. imagine there is no communication going on and daemon starts writing something to the device. In case we remove the check we'll be doing fcopy_respond_to_host() for each daemon's write flooding the host. > If there is a timeout > scheduled some return value will be sent to the host. Then the state is > set to RESET and eventually vmbus_recvpacket will receive something. > That something will be processed and passed to the daemon. > > If there was no timeout scheduled the write will just return. yes, but after doing fcopy_respond_to_host(). I'd suggest we leave the check in place, better safe than sorry. -- Vitaly _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
