From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org
Cc: jsnow@redhat.com, kwolf@redhat.com, qemu-block@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] nbd/client: add x-block-status hack for testing server
Date: Fri, 29 Jun 2018 10:55:20 -0500 [thread overview]
Message-ID: <fc71b8ce-eefb-8a8b-6bd3-3d55baf0bc63@redhat.com> (raw)
In-Reply-To: <c4c1dc69-9d64-435b-1dab-c1edfa6ce2bd@virtuozzo.com>
On 06/29/2018 05:01 AM, Vladimir Sementsov-Ogievskiy wrote:
> Sorry for being late, here are some thoughts. Anyway, idea is good,
> we've planned to do something like this, but you were the first)
Actually, I'm now leaning towards a bit more extensive improvement that
would let 'qemu-img map --output=json' show BOTH normal block status AND
the NBD dirty bitmap status at once (that is, let the client query two
status fields at once when passing an NBD option, rather than this
hack's approach of replacing normal block status with just dirty bitmap
status). We'll see if I can come up with something before 3.0
softfreeze (at any rate, I have my work cut out for me today).
>> +++ b/qapi/block-core.json
>> @@ -3484,12 +3484,22 @@
>> #
>> # @tls-creds: TLS credentials ID
>> #
>> +# @x-block-status: A string containing a semicolon-separated list of
>> +# block status context names to query and then
>> +# request
>
> and then request only the first one
Ideally, I'd like to report dirty bitmap in addition to normal block
status (and actually, we really only need to support exactly one string,
none of this semicolon-separated stuff). We'll see where v2 gets us; but
yes, this v1 hack uses only the first string.
My v1 hack served two purposes: stress-test the server (where the
semicolon separation DID let me slam multiple requests, with multiple
different spellings, to double-check that I was happy with the server's
response in all cases), and hack a single reader for bitmap status; only
the latter one is important in the long run.
>> @@ -438,8 +443,8 @@ static int nbd_open(BlockDriverState *bs, QDict
>> *options, int flags,
>> }
>>
>> /* NBD handshake */
>> - ret = nbd_client_init(bs, sioc, s->export,
>> - tlscreds, hostname, errp);
>> + ret = nbd_client_init(bs, sioc, s->export, tlscreds, hostname,
>> + qemu_opt_get(opts, "x-block-status"), errp);
>
> hm, so, after this nbd_open finish, info.x_block_status will become
> invalid pointer..
> It's not used in other places, but looks like bad idea anyway. If we
> don't want to allocate string,
> we can pass it as a separate const char* paramter to nbd_receive_negotiate.
As a hack, I just plumbed in the bare minimum to get from command line
to the wire. Yes, a more formal patch would have to strdup() something
to last for the proper lifetime, and maybe pass it through via a struct
rather than having to add yet more parameters for future additions.
>> +/* nbd_negotiate_list_meta_context:
>> + * Hack for testing meta context negotiation. Subdivide list on
>> semicolons,
>> + * then pass that many queries for info and trace the results.
>> + * return 0 for successful negotiation
>> + * -1 with errp set for any other error
>> + */
>> +static int nbd_negotiate_list_meta_context(QIOChannel *ioc,
>> + const char *export,
>> + const char *context,
>> + Error **errp)
>> +{
>
> hm, I'd prefer to refactor this, to not duplicate code.. this function
> (may be a bit improved) may be called from
> nbd_negotiate_simple_meta_context(), and we will test normal code path
> when debugging with the hack.
> However, I'm ok with this duplication for now, as a debugging hack.
Yes, very true. I did a LOT of copy-and-paste which would be nicer as
parameterized reusable code.
>> + while (reply.type == NBD_REP_META_CONTEXT) {
>> + char *name;
>> +
>
> don't you want to check reply.length before read?
Yes, in a formal patch, we must not trust that the server is
non-malicious. It might be worth refactoring cleanup along the lines of
nbd_opt_read() in server.c that guarantees that a subsequent read fits
within a predetermined remaining length, for less code at each point in
the sequence that has to do such length validations.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
prev parent reply other threads:[~2018-06-29 15:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-21 3:25 [Qemu-devel] [PATCH] nbd/client: add x-block-status hack for testing server Eric Blake
2018-06-21 5:45 ` no-reply
2018-06-21 15:09 ` Eric Blake
2018-06-21 5:53 ` no-reply
2018-06-29 15:53 ` Eric Blake
2018-06-25 13:50 ` Max Reitz
2018-06-25 17:12 ` John Snow
2018-06-29 10:01 ` Vladimir Sementsov-Ogievskiy
2018-06-29 15:55 ` Eric Blake [this message]
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=fc71b8ce-eefb-8a8b-6bd3-3d55baf0bc63@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).