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