qemu/qemu/dfbf16e2ade627962cda817f550f110fe1d59644 nbd/server: accept NBD_CMD_CACHE above the maximum payload size
NBD_CMD_CACHE carries no payload in either direction. The request is
a header only, nbd_do_cmd_cache() passes a NULL qiov to
blk_co_preadv(), and the reply is a bare status. Still the server
rejects any effect length above NBD_MAX_BUFFER_SIZE with EINVAL,
which forces a client to split a large prefetch into 32 MiB pieces.
The specification does not ask for this. The constraint was renamed
from "maximum block size" to "maximum payload size" precisely to
separate payload length from effect length, and it says:
For commands that do not require a payload in either direction
(such as NBD_CMD_TRIM or NBD_CMD_WRITE_ZEROES), the client MAY
request an effect length larger than the maximum payload size;
the server SHOULD NOT disconnect, but MAY reply with an
NBD_EOVERFLOW or NBD_EINVAL error if the oversize request would
require too many server resources when compared to the same
command with an effect length limited to the maximum payload
size (such as an implementation of NBD_CMD_WRITE_ZEROES that
utilizes a scratch buffer).
We already follow that for NBD_CMD_TRIM and NBD_CMD_WRITE_ZEROES,
which carry no length check at all, and our client assumes a server
supporting extended headers takes unlimited zero and trim lengths.
Handle NBD_CMD_CACHE in the same way.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: Eric Blake <eblake@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20260827161002.310688-3-den@openvz.org>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
2 files changed