On Wed, Nov 24, 2021 at 03:09:51PM +0100, Vladimir Sementsov-Ogievskiy wrote:
> Reconnect feature was never prepared to handle server options changed
> on reconnect. Let's be stricter and check what exactly is changed. If
> server capabilities just got richer don't worry. Otherwise fail and
> drop the established connection.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
> ---
> + /*
> + * No worry if rotational status changed. But other flags are feature
> flags,
> + * they should not degrade.
> + */
> + dropped_flags = (old->flags & ~new->flags) & ~NBD_FLAG_ROTATIONAL;
> + if (dropped_flags) {
> + error_setg(errp, "Server options degrade after reconnect: flags 0x%"
> + PRIx32 " are not reported anymore", dropped_flags);
> + return false;
> + }
Your logic is good for most flags, but somewhat wrong for
NBD_FLAG_READ_ONLY_BIT. For cases where we are only using the block
device read-only, we don't care about changes of that bit, in either
direction. But for cases where we want to use the block device
read-write, the bit changing from clear in the old to set in the new
server is an incompatible change that your logic failed to flag.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
