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 <lizzha@microsoft.com> for the initial investigation on the bug. This addresses https://bugzilla.redhat.com/show_bug.cgi?id=1118123
Unified · Split
| @@ -246,8 +246,8 @@ void hv_fcopy_onchannelcallback(void *context) · 245 unmodified lines | ||
| 246 | 246 | /* |
| 247 | 247 | * Send the information to the user-level daemon. |
| 248 | 248 | */ |
| 249 | − fcopy_send_data(); | |
| 250 | 249 | schedule_delayed_work(&fcopy_work, 5*HZ); |
| 250 | + fcopy_send_data(); | |
| 251 | 251 | return; |
| 252 | 252 | } |
| 253 | 253 | icmsghdr->icflags = ICMSGHDRFLAG_TRANSACTION | ICMSGHDRFLAG_RESPONSE; |