We should schedule the 5s "timer work" before starting the data transfer, otherwise, the data transfer code may finish so fast on another virtual cpu that when the code(fcopy_write()) trying to cancel the 5s "timer work" can occasionally fail because the "timer work" may haven't been scheduled yet and as a result the fcopy process will be aborted wrongly by fcopy_work_func() in 5s.
Thank Liz Zhang <liz...@microsoft.com> for the initial investigation on the bug. This addresses https://bugzilla.redhat.com/show_bug.cgi?id=1118123 Tested-by: Liz Zhang <liz...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: sta...@vger.kernel.org Signed-off-by: Dexuan Cui <de...@microsoft.com> --- drivers/hv/hv_fcopy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c index eaaa3d8..23b2ce2 100644 --- a/drivers/hv/hv_fcopy.c +++ b/drivers/hv/hv_fcopy.c @@ -246,8 +246,8 @@ void hv_fcopy_onchannelcallback(void *context) /* * Send the information to the user-level daemon. */ - fcopy_send_data(); schedule_delayed_work(&fcopy_work, 5*HZ); + fcopy_send_data(); return; } icmsghdr->icflags = ICMSGHDRFLAG_TRANSACTION | ICMSGHDRFLAG_RESPONSE; -- 1.9.1 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
