From: Eric Blake <eblake@redhat.com>
To: qemu-devel@nongnu.org
Cc: qemu-trivial@nongnu.org, pannengyuan@huawei.com,
laurent@vivier.eu, qemu-block@nongnu.org
Subject: [PATCH] nbd: Fix regression with multiple meta contexts
Date: Thu, 6 Feb 2020 11:38:32 -0600 [thread overview]
Message-ID: <20200206173832.130004-1-eblake@redhat.com> (raw)
Detected by a hang in the libnbd testsuite. If a client requests
multiple meta contexts (both base:allocation and qemu:dirty-bitmap:x)
at the same time, our attempt to silence a false-positive warning
about a potential uninitialized variable introduced botched logic: we
were short-circuiting the second context, and never sending the
NBD_REPLY_FLAG_DONE. Combining two 'if' into one 'if/else' in
bdf200a55 was wrong (I'm a bit embarrassed that such a change was my
initial suggestion after the v1 patch, then I did not review the v2
patch that actually got committed). Revert that, and instead silence
the false positive warning by replacing 'return ret' with 'return 0'
(the value it always has at that point in the code, even though it
eluded the deduction abilities of the robot that reported the false
positive).
Fixes: bdf200a5535
Signed-off-by: Eric Blake <eblake@redhat.com>
---
It's never fun when a regression is caused by a patch taken through
qemu-trivial, proving that the patch was not trivial after all.
nbd/server.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/nbd/server.c b/nbd/server.c
index 87fcd2e7bfac..11a31094ff83 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -2384,15 +2384,23 @@ static coroutine_fn int nbd_handle_request(NBDClient *client,
!client->export_meta.bitmap,
NBD_META_ID_BASE_ALLOCATION,
errp);
- } else { /* client->export_meta.bitmap */
+ if (ret < 0) {
+ return ret;
+ }
+ }
+
+ if (client->export_meta.bitmap) {
ret = nbd_co_send_bitmap(client, request->handle,
client->exp->export_bitmap,
request->from, request->len,
dont_fragment,
true, NBD_META_ID_DIRTY_BITMAP, errp);
+ if (ret < 0) {
+ return ret;
+ }
}
- return ret;
+ return 0;
} else {
return nbd_send_generic_reply(client, request->handle, -EINVAL,
"CMD_BLOCK_STATUS not negotiated",
--
2.24.1
next reply other threads:[~2020-02-06 17:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 17:38 Eric Blake [this message]
2020-02-06 17:54 ` [PATCH] nbd: Fix regression with multiple meta contexts Laurent Vivier
2020-02-12 9:24 ` Laurent Vivier
2020-02-12 12:10 ` Eric Blake
2020-02-12 12:13 ` Laurent Vivier
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=20200206173832.130004-1-eblake@redhat.com \
--to=eblake@redhat.com \
--cc=laurent@vivier.eu \
--cc=pannengyuan@huawei.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/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).