From: Peter Xu <peterx@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, Fam Zheng <famz@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] qtest: fix "device_del" out-of-order events
Date: Wed, 13 Sep 2017 18:28:42 +0800 [thread overview]
Message-ID: <20170913102842.GE3617@pxdev.xzpeter.org> (raw)
In-Reply-To: <f7707221-5365-8074-7a83-ac108059aecc@redhat.com>
On Wed, Sep 13, 2017 at 11:53:16AM +0200, Thomas Huth wrote:
> On 13.09.2017 11:36, Peter Xu wrote:
> > It starts from a "make check" failure on one of my private tree. The
> > problem is that when we do "device_del" we normally looking for two
> > things: one response (which is mostly empty), and a REMOVE event. The
> > tricky point is the event can either be there before/after the empty
> > response. So I added qmp_device_del() to make sure the order does not
> > matter, then use it where proper.
> >
> > Since I'm at it, I also added the sister helper qmp_device_add(), it
> > helps to remove LOCs.
>
> I've had a similar idea a couple of weeks ago, see here:
>
> http://patchwork.ozlabs.org/patch/801487/
Good to know!
>
> > I still don't 100% sure why my private tree can trigger this error,
> > while the master cannot. Anyway, I think this is something we should
> > have, no matter what.
>
> Did you maybe touch the USB tests in your private tree?
No. But I changed some internals of QMP there, I guess that's the
reason that caused the misorder to happen more easily.
> As far as I know, some test currently use QMP in a bad way, for example
> usb_test_hotplug() only checks for the DEVICE_DELETED at the end, but
> forgets to read back the final return value. That return value is then
> presented to the next part of the code that uses QMP instead ... it
> currently only works more or less by accident, but as soon as you try to
> add new code inbetween, it certainly will fail.
> ==> We really got to clean this up (either with my patch or your patch
> series).
Agree.
I think your patch is nicer on the interface (as you have mentioned in
the other reply), I can try to review it later.
However it seems that your patch didn't really solve the problem I
encountered (mis-ordered message arrivals). It would be good if you
want to solve it together, or I can draft patch upon yours.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2017-09-13 10:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-13 9:36 [Qemu-devel] [PATCH 0/4] qtest: fix "device_del" out-of-order events Peter Xu
2017-09-13 9:36 ` [Qemu-devel] [PATCH 1/4] libqtest: add qmp_device_del() Peter Xu
2017-10-02 17:25 ` Markus Armbruster
2017-10-02 17:33 ` Eric Blake
2017-09-13 9:36 ` [Qemu-devel] [PATCH 2/4] tests: use qmp_device_del() where proper Peter Xu
2017-09-13 9:36 ` [Qemu-devel] [PATCH 3/4] libqtest: add qmp_device_add() Peter Xu
2017-09-13 10:01 ` Thomas Huth
2017-09-13 9:36 ` [Qemu-devel] [PATCH 4/4] tests: use qmp_device_add() where proper Peter Xu
2017-09-13 9:53 ` [Qemu-devel] [PATCH 0/4] qtest: fix "device_del" out-of-order events Thomas Huth
2017-09-13 10:28 ` Peter Xu [this message]
2017-09-13 10:35 ` Thomas Huth
2017-09-13 10:42 ` Peter Xu
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=20170913102842.GE3617@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.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 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.