[lkml]   [2017]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH V2 2/4] Drivers: hv: fcopy: restore correct transfer length
On Sun, Sep 17, 2017 at 08:54:17PM -0700, wrote:
> From: Olaf Hering <>
> 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...

 \ /
  Last update: 2017-09-18 16:00    [W:0.100 / U:20.308 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site