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

[KY Srinivasan]

> -----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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/