From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: peterx@redhat.com, Paolo Bonzini <pbonzini@redhat.com>
Subject: [Qemu-devel] [PATCH for-2.11] rcu: init globals only once
Date: Tue, 8 Aug 2017 15:00:07 +0800 [thread overview]
Message-ID: <1502175607-9531-1-git-send-email-peterx@redhat.com> (raw)
We were calling rcu_init_complete() twice in the child processes when
fork happened. However the pthread library does not really suggest to do
it that way:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_init.html
"Attempting to initialise an already initialised mutex results in
undefined behaviour."
Actually, IMHO we can do it in a more natural way: Firstly, we only init
the RCU globals once in rcu_init(). Then, in rcu_init_child(), we unlock
all the locks held in rcu_init_lock() just like what we do in the parent
process, then do the rest of RCU re-init (e.g., create the RCU thread).
CC: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
---
this is based on Paolo's series:
"[PATCH for-2.10 0/2] RCU: forking fix and cleanups"
---
util/rcu.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/util/rcu.c b/util/rcu.c
index ca5a63e..6fbbe4c 100644
--- a/util/rcu.c
+++ b/util/rcu.c
@@ -299,15 +299,17 @@ void rcu_unregister_thread(void)
qemu_mutex_unlock(&rcu_registry_lock);
}
-static void rcu_init_complete(void)
+static void rcu_init_globals(void)
{
- QemuThread thread;
-
qemu_mutex_init(&rcu_registry_lock);
qemu_mutex_init(&rcu_sync_lock);
qemu_event_init(&rcu_gp_event, true);
-
qemu_event_init(&rcu_call_ready_event, false);
+}
+
+static void rcu_init_complete(void)
+{
+ QemuThread thread;
/* The caller is assumed to have iothread lock, so the call_rcu thread
* must have been quiescent even after forking, just recreate it.
@@ -357,6 +359,13 @@ static void rcu_init_child(void)
return;
}
+ rcu_init_unlock();
+
+ /*
+ * For the newly forked child, we need something extra: since
+ * after fork the threads are all gone, we need to re-init the RCU
+ * thread, along with the globals.
+ */
memset(®istry, 0, sizeof(registry));
rcu_init_complete();
}
@@ -367,5 +376,6 @@ static void __attribute__((__constructor__)) rcu_init(void)
#ifdef CONFIG_POSIX
pthread_atfork(rcu_init_lock, rcu_init_unlock, rcu_init_child);
#endif
+ rcu_init_globals();
rcu_init_complete();
}
--
2.7.4
next reply other threads:[~2017-08-08 7:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 7:00 Peter Xu [this message]
2017-08-08 7:26 ` [Qemu-devel] [PATCH for-2.11] rcu: init globals only once Paolo Bonzini
2017-08-08 7:49 ` Peter Xu
2017-08-08 8:15 ` Paolo Bonzini
2017-08-08 14:09 ` Eric Blake
2017-08-09 3:25 ` 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=1502175607-9531-1-git-send-email-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@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 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.