[fixing some of my editing errors] On Fri, Jun 09, 2023 at 10:42:25AM -0500, Eric Blake wrote: [...] > > The tl;dr summary of the above discourse: > There are two orthogonal communications going on: > > libnbd <-> server choice of NBD_REPLY_TYPE_BLOCK_STATUS{,_EXT} > app <-> libnbd choice of nbd_block_status() or nbd_block_status_64() > > and all four combinations are easy to encounter when loading the .so > for libnbd 1.18: > > 32 x 32 (app compiled against libnbd 1.16 to server A) > 64 x 32 (app compiled against libnbd 1.16 to server B) > 32 x 64 (app compiled against libnbd 1.18 to server A) > 64 x 64 (app compiled against libnbd 1.18 to server B) > > and we want all four combinations to work insofar as possible. 32x32 > and 64x64 obviously work, as does 32x64 (widening the server's > responses never fails); for 32x64 (using the 32-bit nbd_block_status() > API to access a server's response through 64-bit > NBD_REPLY_TYPE_BLOCK_STATUS), accessing a metacontext with large flags
for 64x32 (using the 32-bit nbd_block_status() to access a server's response through 64-bit NBD_REPLY_TYPE_BLOCK_STATUS_EXT), > changes from fail early to fail late; and accessing a metacontext with > 32-bit flags but now potential 64-bit lengths obeys overall NBD > semantics that a block status response can be truncated as long as it > makes progress (the app shouldn't care whether it was the server or > libnbd that did the truncation). > [...] > > It is indeed a bug if a server replies with > NBD_REPLY_TYPE_BLOCK_STATUS_EXT for a client that did not request > extended headers. But it is also a bug if a server replise with replies > NBD_REPLY_TYPE_BLOCK_STATUS for a client that did request extended > headers, even if the reply does not need more than 32 bits for either > the length or the flags. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org