nbd/server: Fix error reporting for bad requests
commitfed5f8f82056c9f222433c41aeb9fca50c89f297
authorEric Blake <eblake@redhat.com>
Wed, 15 Nov 2017 21:35:56 +0000 (15 15:35 -0600)
committerEric Blake <eblake@redhat.com>
Fri, 17 Nov 2017 14:38:38 +0000 (17 08:38 -0600)
treea2429bc787f2916307d8250b79644f81bce6cb41
parent01b05c66a3616d5a4adc39fc90962e9efaf791d1
nbd/server: Fix error reporting for bad requests

The NBD spec says an attempt to NBD_CMD_TRIM on a read-only
export should fail with EPERM, as a trim has the potential
to change disk contents, but we were relying on the block
layer to catch that for us, which might not always give the
right error (and even if it does, it does not let us pass
back a sane message for structured replies).

The NBD spec says an attempt to NBD_CMD_WRITE_ZEROES out of
bounds should fail with ENOSPC, not EINVAL.

Our check for u64 offset + u32 length wraparound up front is
pointless; nothing uses offset until after the second round
of sanity checks, and we can just as easily ensure there is
no wraparound by checking whether offset is in bounds (since
a disk size cannot exceed off_t which is 63 bits, adding a
32-bit number for a valid offset can't overflow).  Bonus:
dropping the up-front check lets us keep the connection alive
after NBD_CMD_WRITE, whereas before we would drop the
connection (of course, any client sending a packet that would
trigger the failure is already buggy, so it's also okay to
drop the connection, but better quality-of-implementation
never hurts).

Solve all of these issues by some code motion and improved
request validation.

Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20171115213557.3548-1-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
nbd/server.c