All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Liu Ping Fan <qemulist@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	mdroth <mdroth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC PATCH v4 15/15] slirp: use lock to protect the slirp_instances
Date: Thu, 18 Apr 2013 09:20:12 +0200	[thread overview]
Message-ID: <516F9EAC.6090804@siemens.com> (raw)
In-Reply-To: <1366187964-14265-16-git-send-email-qemulist@gmail.com>

On 2013-04-17 10:39, Liu Ping Fan wrote:
> From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> 
> slirps will run on dedicated thread, so need to protect the global
> list.
> 
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> ---
>  include/qemu/module.h |    2 ++
>  slirp/slirp.c         |   20 ++++++++++++++++++++
>  2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/include/qemu/module.h b/include/qemu/module.h
> index c4ccd57..2720943 100644
> --- a/include/qemu/module.h
> +++ b/include/qemu/module.h
> @@ -22,6 +22,7 @@ static void __attribute__((constructor)) do_qemu_init_ ## function(void) {  \
>  
>  typedef enum {
>      MODULE_INIT_BLOCK,
> +    MODULE_INIT_SLIRP,
>      MODULE_INIT_MACHINE,
>      MODULE_INIT_QAPI,
>      MODULE_INIT_QOM,
> @@ -29,6 +30,7 @@ typedef enum {
>  } module_init_type;
>  
>  #define block_init(function) module_init(function, MODULE_INIT_BLOCK)
> +#define slirplayer_init(function) module_init(function, MODULE_INIT_SLIRP)
>  #define machine_init(function) module_init(function, MODULE_INIT_MACHINE)
>  #define qapi_init(function) module_init(function, MODULE_INIT_QAPI)
>  #define type_init(function) module_init(function, MODULE_INIT_QOM)
> diff --git a/slirp/slirp.c b/slirp/slirp.c
> index 6bfcc67..4cbf04d 100644
> --- a/slirp/slirp.c
> +++ b/slirp/slirp.c
> @@ -42,6 +42,7 @@ static const uint8_t zero_ethaddr[ETH_ALEN] = { 0, 0, 0, 0, 0, 0 };
>  
>  u_int curtime;
>  
> +static QemuMutex slirp_instances_lock;
>  static QTAILQ_HEAD(slirp_instances, Slirp) slirp_instances =
>      QTAILQ_HEAD_INITIALIZER(slirp_instances);
>  
> @@ -236,14 +237,18 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
>      register_savevm(NULL, "slirp", 0, 3,
>                      slirp_state_save, slirp_state_load, slirp);
>  
> +    qemu_mutex_lock(&slirp_instances_lock);
>      QTAILQ_INSERT_TAIL(&slirp_instances, slirp, entry);
> +    qemu_mutex_unlock(&slirp_instances_lock);
>  
>      return slirp;
>  }
>  
>  void slirp_cleanup(Slirp *slirp)
>  {
> +    qemu_mutex_lock(&slirp_instances_lock);
>      QTAILQ_REMOVE(&slirp_instances, slirp, entry);
> +    qemu_mutex_unlock(&slirp_instances_lock);
>  
>      unregister_savevm(NULL, "slirp", slirp);
>  
> @@ -262,9 +267,12 @@ void slirp_cleanup(Slirp *slirp)
>  
>  void slirp_update_timeout(uint32_t *timeout)
>  {
> +    qemu_mutex_lock(&slirp_instances_lock);
>      if (!QTAILQ_EMPTY(&slirp_instances)) {
>          *timeout = MIN(1000, *timeout);
>      }
> +    qemu_mutex_unlock(&slirp_instances_lock);
> +
>      curtime = qemu_get_clock_ms(rt_clock);
>  }
>  
> @@ -1140,3 +1148,15 @@ static int slirp_state_load(QEMUFile *f, void *opaque, int version_id)
>  
>      return 0;
>  }
> +
> +static void slirplayer_cleanup(void)
> +{
> +    qemu_mutex_destroy(&slirp_instances_lock);
> +}
> +
> +static void slirplayer_bootup(void)
> +{
> +    qemu_mutex_init(&slirp_instances_lock);
> +    atexit(&slirplayer_cleanup);
> +}
> +slirplayer_init(slirplayer_bootup)
> 

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").

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2013-04-18  7:20 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 [this message]
2013-04-18 14:16     ` Paolo Bonzini
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=516F9EAC.6090804@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=anthony@codemonkey.ws \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.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.