On 10/14/2016 04:02 PM, Eric Blake wrote: > Any client attempting to probe support for a new option, such as > NBD_OPT_STARTTLS or NBD_OPT_GO, with plans to do a graceful > fallback to older methods, will fail in its attempt if the server > does not ignore the length field and potential payload of the > unrecognized (or rejected) option, because the server will then > be reading out of sync and not see the client's magic for the > next option. This bug has been latent in the reference > server since commit 626c2a3 in 2012, even though it is EXACTLY > the bug that NBD_FLAG_FIXED_NEWSTYLE was designed to prevent. Given that we have 4 years of buggy servers that will fail to react correctly to NBD_OPT_GO and friends, is it worth enhancing the docs to suggest that a robust client should be prepared for (buggy) servers that mistakenly hang up after sending an NBD_OPT_ERR_UNSUP, and try reconnecting to the server while avoiding the command that failed on the previous run? Eventually, buggy servers will disappear, so we can't mandate that clients take that extra step, but since it is a very common problem at the present, it might help client implementations to be aware of it. Then again, most client implementors read this list, so documenting it in the protocol may be overkill. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature