On Fri, Oct 09, Vitaly Kuznetsov wrote: > Olaf Hering <olaf@xxxxxxxxx> writes: > > > On Thu, Oct 08, KY Srinivasan wrote: > > > >> > 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. > > > > I will retest with this part reverted. I think without two code paths > > entering hv_fcopy_callback it should be ok to leave this check in. > > I think hv_fcopy_callback() is not involved here: we call fcopy_on_msg() > every time userspace daemon writes to the device and it is not anyhow > synchronized with host-guest communication. An earlier variant of this patch used locks around the vmbus_recvpacket and the result was used to decide which thread of execution notifies the daemon. I think if the interrupt ran earlier than the daemon did the write then the state expected in fcopy_on_msg would obviously be wrong. As a result the daemon will just terminate with EFAULT. With the check removed it would proceed, and either not chancel the timeout or vmbus_recvpacket reads nothing. But now that it is single threaded the state in fcopy_on_msg should be as expected. As said, will retest. Either later today or on Monday. Olaf _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
