diff options
author | Eric Blake <eblake@redhat.com> | 2017-10-27 12:40:29 +0200 |
---|---|---|
committer | Eric Blake <eblake@redhat.com> | 2017-10-30 21:07:44 +0100 |
commit | 8fb48b8b38a895cbb17a601829603365c4938f60 (patch) | |
tree | 4e66adbda576f1f39a8959be916f86edc5306597 /dump.c | |
parent | bae245d19a7fae77410cb8b09350b672df689a66 (diff) | |
download | qemu-8fb48b8b38a895cbb17a601829603365c4938f60.zip qemu-8fb48b8b38a895cbb17a601829603365c4938f60.tar.gz qemu-8fb48b8b38a895cbb17a601829603365c4938f60.tar.bz2 |
nbd/server: Report error for write to read-only export
When the server is read-only, we were already reporting an error
message for NBD_CMD_WRITE_ZEROES, but failed to set errp for a
similar NBD_CMD_WRITE. This will matter more once structured
replies allow the server to propagate the errp information back
to the client. While at it, use an error message that makes a
bit more sense if viewed on the client side.
Note that when using qemu-io to test qemu-nbd behavior, it is
rather difficult to convince qemu-io to send protocol violations
(such as a read beyond bounds), because we have a lot of active
checking on the client side that a qemu-io request makes sense
before it ever goes over the wire to the server. The case of a
client attempting a write when the server is started as
'qemu-nbd -r' is one of the few places where we can easily test
error path handling, without having to resort to hacking in known
temporary bugs to either the server or client. [Maybe we want a
future patch to the client to do up-front checking on writes to a
read-only export, the way it does up-front bounds checking; but I
don't see anything in the NBD spec that points to a protocol
violation in our current behavior.]
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20171027104037.8319-5-eblake@redhat.com>
Diffstat (limited to 'dump.c')
0 files changed, 0 insertions, 0 deletions