> -----Original Message----- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Thursday, October 8, 2015 6:53 AM > To: Olaf Hering <o...@aepfle.de> > Cc: KY Srinivasan <k...@microsoft.com>; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; a...@canonical.com; > jasow...@redhat.com > Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in > interrupt context > > Olaf Hering <o...@aepfle.de> 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.
Agreed; Olaf, if it is ok with you, I can fix it up and send. Regards, K. Y > > -- > Vitaly _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
