On Sun, Sep 17, 2017 at 08:54:17PM -0700, k...@exchange.microsoft.com wrote:
> From: Olaf Hering <o...@aepfle.de>
>
> 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
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
