diff options
| author | Eric Blake <eblake@redhat.com> | 2016-07-21 13:34:46 -0600 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2016-08-03 18:44:56 +0200 |
| commit | 7423f417827146f956df820f172d0bf80a489495 (patch) | |
| tree | c344d494cc4fab46a7bb1daacb0088bc35e9ee1f /include/hw/nvram/fw_cfg_keys.h | |
| parent | 5bee0f4717c4c67394aaade0c5a9cee3d42cc614 (diff) | |
nbd: Limit nbdflags to 16 bits
Rather than asserting that nbdflags is within range, just give
it the correct type to begin with :) nbdflags corresponds to
the per-export portion of NBD Protocol "transmission flags", which
is 16 bits in response to NBD_OPT_EXPORT_NAME and NBD_OPT_GO.
Furthermore, upstream NBD has never passed the global flags to
the kernel via ioctl(NBD_SET_FLAGS) (the ioctl was first
introduced in NBD 2.9.22; then a latent bug in NBD 3.1 actually
tried to OR the global flags with the transmission flags, with
the disaster that the addition of NBD_FLAG_NO_ZEROES in 3.9
caused all earlier NBD 3.x clients to treat every export as
read-only; NBD 3.10 and later intentionally clip things to 16
bits to pass only transmission flags). Qemu should follow suit,
since the current two global flags (NBD_FLAG_FIXED_NEWSTYLE
and NBD_FLAG_NO_ZEROES) have no impact on the kernel's behavior
during transmission.
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1469129688-22848-3-git-send-email-eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'include/hw/nvram/fw_cfg_keys.h')
0 files changed, 0 insertions, 0 deletions