Re: [RFC for-6.2] block/nbd: forbid incompatible change of server options on reconnect

[Eric Blake]

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 <vsementsov@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