On Sun, Sep 17, 2017 at 08:54:17PM -0700, kys@xxxxxxxxxxxxxxxxxxxxxx wrote: > From: Olaf Hering <olaf@xxxxxxxxx> > > Till recently the expected length of bytes read by the > daemon did depend on the context. It was either hv_start_fcopy or > hv_do_fcopy. The daemon had a buffer size of two pages, which was much > larger than needed. > > Now the expected length of bytes read by the > daemon changed slightly. For START_FILE_COPY it is still the size of > hv_start_fcopy. But for WRITE_TO_FILE and the other operations it is as > large as the buffer that arrived via vmbus. In case of WRITE_TO_FILE > that is slightly larger than a struct hv_do_fcopy. Since the buffer in > the daemon was still larger everything was fine. > > Currently, the daemon reads only what is actually needed. > The new buffer layout is as large as a struct hv_do_fcopy, for the > WRITE_TO_FILE operation. Since the kernel expects a slightly larger > size, hvt_op_read will return -EINVAL because the daemon will read > slightly less than expected. Address this by restoring the expected > buffer size in case of WRITE_TO_FILE. > > Fixes: 'commit c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport")' > Fixes: 'commit 3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon")' What's with the 'commit' here? It should look like: Fixes: c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport") Please fix... _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel