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>
This commit is contained in:
parent
bae245d19a
commit
8fb48b8b38
@ -1381,6 +1381,7 @@ static coroutine_fn void nbd_trip(void *opaque)
|
||||
break;
|
||||
case NBD_CMD_WRITE:
|
||||
if (exp->nbdflags & NBD_FLAG_READ_ONLY) {
|
||||
error_setg(&local_err, "Export is read-only");
|
||||
ret = -EROFS;
|
||||
break;
|
||||
}
|
||||
@ -1398,7 +1399,7 @@ static coroutine_fn void nbd_trip(void *opaque)
|
||||
break;
|
||||
case NBD_CMD_WRITE_ZEROES:
|
||||
if (exp->nbdflags & NBD_FLAG_READ_ONLY) {
|
||||
error_setg(&local_err, "Server is read-only, return error");
|
||||
error_setg(&local_err, "Export is read-only");
|
||||
ret = -EROFS;
|
||||
break;
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user