On 6/14/19 4:54 PM, Eric Blake wrote:
Any server that sends a reply to NBD_OPT_* or NBD_CMD_* longer than
the maximum length we are willing to use for NBD_CMD_{READ,WRITE} is
probably broken; it is not worth waiting for read() to wait for that
many bytes to arrive from the server to bring the connection back into
sync for the next operation, so just declare it dead.
It may be possible to provoke nbdkit into being such a server when
replying to NBD_CMD_BLOCK_STATUS on a disk that reports alternating
extents, but if so, we should patch nbdkit to truncate before sending
that large of a chunk.
In fact, after an hour of fiddling around, I proved it was possible, and
have since posted/pushed the corresponding nbdkit fix.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org