From: Paolo Bonzini <pbonzini@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: mdroth <mdroth@linux.vnet.ibm.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Liu Ping Fan <qemulist@gmail.com>,
Anthony Liguori <anthony@codemonkey.ws>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH v4 15/15] slirp: use lock to protect the slirp_instances
Date: Thu, 18 Apr 2013 10:16:27 -0400 (EDT) [thread overview]
Message-ID: <1327662508.2685805.1366294587142.JavaMail.root@redhat.com> (raw)
In-Reply-To: <516F9EAC.6090804@siemens.com>
> grep'ing for slirp_instances points to more spots that work with that
> list (QTAILQ_FOREACH, QTAILQ_EMPTY, ...). So the same question here:
> What are the usage rules? When do I _not_ need it when touching the list
> of instances, and why?
>
> Well, I started reading at the top, but there are more lock-adding
> patches in this series. And the more locks we have, the higher the
> probability of ABBA gets. Therefore, please document from the beginning
> the lock order rules that shall prevent it (which may also be "never
> take other locks while holding this one" or "never hold other locks when
> taking this one").
Yeah, the only sane ordering rules should be "hold nothing or just
the BQL when taking this one". Everything else needs a very good
justification...
Paolo
next prev parent reply other threads:[~2013-04-18 14:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-17 8:39 [Qemu-devel] [RFC PATCH v4 00/15] port network layer onto glib Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 01/15] util: introduce gsource event abstration Liu Ping Fan
2013-04-18 14:01 ` Stefan Hajnoczi
2013-04-19 6:52 ` liu ping fan
2013-04-19 11:59 ` Stefan Hajnoczi
2013-04-22 7:50 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 02/15] net: introduce bind_ctx to NetClientInfo Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 03/15] net: port tap onto GSource Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 04/15] net: resolve race of tap backend and its peer Liu Ping Fan
2013-04-18 14:11 ` Stefan Hajnoczi
2013-04-19 5:43 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 05/15] net: port vde onto GSource Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 06/15] net: port socket to GSource Liu Ping Fan
2013-04-18 14:34 ` Stefan Hajnoczi
2013-04-19 5:58 ` liu ping fan
2013-04-19 12:03 ` Stefan Hajnoczi
2013-04-22 7:52 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 07/15] net: port tap-win32 onto GSource Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 08/15] net: hub use lock to protect ports list Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 09/15] net: introduce lock to protect NetQueue Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 10/15] net: introduce lock to protect NetClientState's peer's access Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 11/15] net: make netclient re-entrant with refcnt Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 12/15] slirp: make timeout local Liu Ping Fan
2013-04-18 14:22 ` Paolo Bonzini
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 13/15] slirp: make slirp event dispatch based on slirp instance, not global Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 14/15] slirp: handle race condition Liu Ping Fan
2013-04-18 7:13 ` Jan Kiszka
2013-04-19 0:18 ` liu ping fan
2013-04-19 8:21 ` Jan Kiszka
2013-04-22 5:55 ` liu ping fan
2013-04-23 7:20 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 15/15] slirp: use lock to protect the slirp_instances Liu Ping Fan
2013-04-18 7:20 ` Jan Kiszka
2013-04-18 14:16 ` Paolo Bonzini [this message]
2013-04-19 6:13 ` liu ping fan
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=1327662508.2685805.1366294587142.JavaMail.root@redhat.com \
--to=pbonzini@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
--cc=stefanha@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.