Re: [Qemu-devel] [Nbd] question on ioctl NBD_SET_FLAGS

[Wouter Verhelst <w@uter.be>]

Hi Eric,

On Wed, Apr 20, 2016 at 09:42:02AM -0600, Eric Blake wrote:
[...]
> But in 3.9, the overlap bug was still present, and the set of global
> flags had grown to include NBD_FLAG_NO_ZEROS (commit 038e066), which
> overlaps with NBD_FLAG_READ_ONLY.  Ouch.  This means that a client
> talking to a server that advertises NO_ZEROES means that the client will
> mistakenly tell the kernel to treat EVERY export as read-only, even if
> the client doesn't respond with NBD_FLAG_C_NO_ZEROES.
> 
> 3.10 fixed things; negotiate() now uses uint16_t *flags (instead of u32
> *), and no longer tries to merge global flags with transmission flags;
> only the transmission flags are ever passed to the kernel via
> NBD_SET_FLAGS.  Maybe it's good that there was only 2 weeks between 3.9
> and 3.10, so hopefully few distros are trying to ship that broken version.

Well, yeah, since 3.10 was an "oops" release when 3.9 exposed that bug
(which indeed had existed for a while) and which was reported quite
quickly on the list. Released versions of nbd which have the bug exist
though, and trying to have a 3.8 (or below) client talk to a 3.9 (or
above) server has the same issue.

I decided that there was no way in which I could fix it, and that "the
export is readonly" is bad but not a "critical data loss" kind of bug,
so releasing 3.10 was pretty much the only sane thing I could do (other
than delaying NO_ZEROES, which might have worked too).

[...]
> But do we need to document in the kernel code that existing clients
> mistakenly pass too many bits to the NBD_SET_FLAGS ioctl, so that if we
> ever reach the future point where we need more than 16 transmission
> flags, AND where we have more than 2 global flags defined, existing qemu
> 2.5 clients don't confuse the kernel when calling NBD_SET_FLAGS?  Or do
> we think that it is unlikely enough to worry about, where by the time
> there are more than 16 transmission flags, users are likely to already
> be using new-enough qemu that doesn't send global flags to the kernel?

I'm going to assume the latter is the case, yeah, but we could skip bits
16 and 17 (the only two handshake flags currently defined) and use the
upper 14 bits before using the lower 2 if it does turn out to be a
problem.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12