[PATCH 02/10] Drivers: hv: utils: run polling callback always in interrupt context

KY Srinivasan kys at microsoft.com
Thu Oct 8 14:55:57 UTC 2015



> -----Original Message-----
> From: Vitaly Kuznetsov [mailto:vkuznets at redhat.com]
> Sent: Thursday, October 8, 2015 6:53 AM
> To: Olaf Hering <olaf at aepfle.de>
> Cc: KY Srinivasan <kys at microsoft.com>; gregkh at linuxfoundation.org; linux-
> kernel at vger.kernel.org; devel at linuxdriverproject.org; apw at canonical.com;
> jasowang at redhat.com
> Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in
> interrupt context
> 
> Olaf Hering <olaf at 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


More information about the devel mailing list