All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	 Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	peter.maydell@linaro.com
Subject: Re: [PATCH v6 04/17] nbd: Prepare for 64-bit request effect lengths
Date: Tue, 5 Sep 2023 09:24:35 -0500	[thread overview]
Message-ID: <54b6a72ltz7uvb2lyhlyi4aptz2oaxyb7d5egsj24t7ueibqjb@tds7ps6lfvis> (raw)
In-Reply-To: <3a136ddb-2ea7-ef26-d9b8-7f55f068996c@yandex-team.ru>

On Mon, Sep 04, 2023 at 07:15:04PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 29.08.23 20:58, Eric Blake wrote:
> > Widen the length field of NBDRequest to 64-bits, although we can
> > assert that all current uses are still under 32 bits: either because
> > of NBD_MAX_BUFFER_SIZE which is even smaller (and where size_t can
> > still be appropriate, even on 32-bit platforms), or because nothing
> > ever puts us into NBD_MODE_EXTENDED yet (and while future patches will
> > allow larger transactions, the lengths in play here are still capped
> > at 32-bit).  There are no semantic changes, other than a typo fix in a
> > couple of error messages.
> > 
> > Signed-off-by: Eric Blake <eblake@redhat.com>
> > ---
> > 
> > v6: fix sign extension bug
> > 
> > v5: tweak commit message, adjust a few more spots [Vladimir]
> > 
> > v4: split off enum changes to earlier patches [Vladimir]
> 
> [..]
> 
> > --- a/nbd/server.c
> > +++ b/nbd/server.c
> > @@ -1165,7 +1165,7 @@ static int nbd_negotiate_options(NBDClient *client, Error **errp)
> >           client->optlen = length;
> > 
> >           if (length > NBD_MAX_BUFFER_SIZE) {
> > -            error_setg(errp, "len (%" PRIu32" ) is larger than max len (%u)",
> > +            error_setg(errp, "len (%" PRIu32 ") is larger than max len (%u)",
> >                          length, NBD_MAX_BUFFER_SIZE);
> >               return -EINVAL;
> >           }
> > @@ -1441,7 +1441,7 @@ static int coroutine_fn nbd_receive_request(NBDClient *client, NBDRequest *reque
> >       request->type   = lduw_be_p(buf + 6);
> >       request->cookie = ldq_be_p(buf + 8);
> >       request->from   = ldq_be_p(buf + 16);
> > -    request->len    = ldl_be_p(buf + 24);
> > +    request->len    = (uint32_t)ldl_be_p(buf + 24); /* widen 32 to 64 bits */
> 
> should it be "(uint64_t)" ?

No. ldl_be_p() returns an int.  Widening int to 64 bits sign-extends;
we have to first make it unsigned (by casting to uint32_t) so that we
then have an unsigned value that widens by zero-extension.

Maybe we should fix ldl_bd_p() and friends to favor unsigned values.
'git grep ldul_be' has zero hits; even though Peter just touched the
docs patch claiming it exists:

https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg00645.html


> 
> > 
> >       trace_nbd_receive_request(magic, request->flags, request->type,
> >                                 request->from, request->len);
> > @@ -1899,7 +1899,7 @@ static int coroutine_fn nbd_co_send_simple_reply(NBDClient *client,
> >                                                    NBDRequest *request,
> >                                                    uint32_t error,
> >                                                    void *data,
> > -                                                 size_t len,
> > +                                                 uint64_t len,
> >                                                    Error **errp)
> >   {
> >       NBDSimpleReply reply;
> > @@ -1910,6 +1910,7 @@ static int coroutine_fn nbd_co_send_simple_reply(NBDClient *client,
> >       };
> > 
> >       assert(!len || !nbd_err);
> > +    assert(len <= NBD_MAX_STRING_SIZE);
> 
> NBD_MAX_BUFFER_SIZE ?

No. MAX_STRING_SIZE is 4k, MAX_BUFFER_SIZE is 32M.  The smaller size
is the correct bound here (an error message has to be transmitted as a
single string, and the recipient does not expect more than a 4k error
message).

> 
> with that fixed:
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org



  reply	other threads:[~2023-09-05 14:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 17:58 [PATCH v6 00/17] qemu patches for 64-bit NBD extensions Eric Blake
2023-08-29 17:58 ` [PATCH v6 01/17] nbd: Replace bool structured_reply with mode enum Eric Blake
2023-09-04 15:23   ` Vladimir Sementsov-Ogievskiy
2023-08-29 17:58 ` [PATCH v6 02/17] nbd/client: Pass mode through to nbd_send_request Eric Blake
2023-08-29 17:58 ` [PATCH v6 03/17] nbd: Add types for extended headers Eric Blake
2023-08-29 17:58 ` [PATCH v6 04/17] nbd: Prepare for 64-bit request effect lengths Eric Blake
2023-09-04 16:15   ` Vladimir Sementsov-Ogievskiy
2023-09-05 14:24     ` Eric Blake [this message]
2023-09-05 14:41       ` Vladimir Sementsov-Ogievskiy
2023-09-06 17:18         ` Eric Blake
2023-08-29 17:58 ` [PATCH v6 05/17] nbd/server: Refactor handling of command sanity checks Eric Blake
2023-09-04 16:53   ` Vladimir Sementsov-Ogievskiy
2023-09-25 19:03     ` Eric Blake
2023-08-29 17:58 ` [PATCH v6 06/17] nbd/server: Support a request payload Eric Blake
2023-09-05 14:36   ` Vladimir Sementsov-Ogievskiy
2023-09-06 17:52     ` Eric Blake
2023-09-08 17:43       ` Eric Blake
2023-08-29 17:58 ` [PATCH v6 07/17] nbd/server: Prepare to receive extended header requests Eric Blake
2023-08-29 17:58 ` [PATCH v6 08/17] nbd/server: Prepare to send extended header replies Eric Blake
2023-08-29 17:58 ` [PATCH v6 09/17] nbd/server: Support 64-bit block status Eric Blake
2023-08-29 17:58 ` [PATCH v6 10/17] nbd/server: Enable initial support for extended headers Eric Blake
2023-08-29 17:58 ` [PATCH v6 11/17] nbd/client: Plumb errp through nbd_receive_replies Eric Blake
2023-08-29 17:58 ` [PATCH v6 12/17] nbd/client: Initial support for extended headers Eric Blake
2023-08-29 17:58 ` [PATCH v6 13/17] nbd/client: Accept 64-bit block status chunks Eric Blake
2023-08-29 17:58 ` [PATCH v6 14/17] nbd/client: Request extended headers during negotiation Eric Blake
2023-08-29 17:58 ` [PATCH v6 15/17] nbd/server: Refactor list of negotiated meta contexts Eric Blake
2023-08-29 17:58 ` [PATCH v6 16/17] nbd/server: Prepare for per-request filtering of BLOCK_STATUS Eric Blake
2023-08-29 17:58 ` [PATCH v6 17/17] nbd/server: Add FLAG_PAYLOAD support to CMD_BLOCK_STATUS Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54b6a72ltz7uvb2lyhlyi4aptz2oaxyb7d5egsj24t7ueibqjb@tds7ps6lfvis \
    --to=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.