> -----Original Message----- > From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] > Sent: Thursday, October 8, 2015 6:53 AM > To: Olaf Hering <olaf@xxxxxxxxx> > Cc: KY Srinivasan <kys@xxxxxxxxxxxxx>; gregkh@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx; > jasowang@xxxxxxxxxx > Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in > interrupt context > > 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. Agreed; Olaf, if it is ok with you, I can fix it up and send. Regards, K. Y > > -- > Vitaly _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
