| Message ID | 20171019222637.17890-5-eblake@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | nbd minimal structured read | expand |
20.10.2017 01:26, Eric Blake wrote: > 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>
diff --git a/nbd/server.c b/nbd/server.c index efb6003364..05ff7470d5 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -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; }
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> --- v5: new patch --- nbd/server.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)