summaryrefslogtreecommitdiffstats
path: root/util/rcu.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert "rcu: init rcu_registry_lock after fork"Paolo Bonzini2015-09-161-6/+1
| | | | | | | | This reverts commit 5243722376873a48e9852a58b91f4d4101ee66e4. The patch forgot about rcu_sync_lock and was committed by mistake. Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: init rcu_registry_lock after forkEmilio G. Cota2015-09-091-1/+6
| | | | | | | | | We were unlocking this lock after fork, which is wrong since only the thread that holds a mutex is allowed to unlock it. Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <1440375847-17603-9-git-send-email-cota@braap.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: Allow calling rcu_(un)register_thread() during synchronize_rcu()Wen Congyang2015-08-141-13/+35
| | | | | | | | | | | | | | If rcu_(un)register_thread() is called together with synchronize_rcu(), it will wait for the synchronize_rcu() to finish. But when synchronize_rcu() waits for some events, we can modify the list registry. We also use the lock rcu_gp_lock to assume that synchronize_rcu() isn't executed in more than one thread at the same time. Add a new mutex lock rcu_sync_lock to assume it and rename rcu_gp_lock to rcu_registry_lock. Release rcu_registry_lock when synchronize_rcu() waits for some events. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Message-Id: <55B59652.4090503@cn.fujitsu.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: actually register threads that have RCU read-side critical sectionsPaolo Bonzini2015-07-241-0/+2
| | | | | | Otherwise, grace periods are detected too early! Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: do not create thread in pthread_atfork callbackPaolo Bonzini2015-04-011-4/+3
| | | | | | | | | | | | | | | | | | | | | If QEMU forks after the CPU threads have been created, qemu_mutex_lock_iothread will not be able to do qemu_cpu_kick_thread. There is no solution other than assuming that forks after the CPU threads have been created will end up in an exec. Forks before the CPU threads have been created (such as -daemonize) have to call rcu_after_fork manually. Notably, the oxygen theme for GTK+ forks and shows a "No such process" error without this patch. This patch can be reverted once the iothread loses the "kick the TCG thread" magic. User-mode emulation does not use the iothread, so it can also call rcu_after_fork. Reported by: Dr. David Alan Gilbert <dgilbert@redhat.com> Tested by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: handle forks safelyPaolo Bonzini2015-03-101-1/+32
| | | | | | | | | | | | | | After forking, only the calling thread is duplicated in the child process. The call_rcu thread has to be recreated in the child. Exploit the fact that only one thread exists (same as when constructors run), and just redo the entire initialization to ensure the threads are in the proper state. The only additional things to do are emptying the list of threads registered with RCU, and unlocking the lock that was taken in the prepare callback (implementations are allowed to fail pthread_mutex_init() if the mutex is still locked). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: run RCU callbacks under the BQLPaolo Bonzini2015-02-111-0/+5
| | | | | | | | | | This needs to go away sooner or later, but one complication is the complex VFIO data structures that are modified in instance_finalize. Take a shortcut for now. Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: do not let RCU callbacks pile up indefinitelyPaolo Bonzini2015-02-111-6/+8
| | | | | | | | | Always process them within a short time. Even though waiting a little is useful, it is not okay to delay e.g. qemu_opts_del forever. Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: add call_rcuPaolo Bonzini2015-02-021-0/+119
| | | | | | | | | | | | Asynchronous callbacks provided by call_rcu are particularly important for QEMU, because the BQL makes it hard to use synchronize_rcu. In addition, the current RCU implementation is not particularly friendly to multiple concurrent synchronize_rcu callers, making call_rcu even more important. Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* rcu: add rcu libraryPaolo Bonzini2015-02-021-0/+172
This includes a (mangled) copy of the liburcu code. The main changes are: 1) removing dependencies on many other header files in liburcu; 2) removing for simplicity the tentative busy waiting in synchronize_rcu, which has limited performance effects; 3) replacing futexes in synchronize_rcu with QemuEvents for Win32 portability. The API is the same as liburcu, so it should be possible in the future to require liburcu on POSIX systems for example and use our copy only on Windows. Among the various versions available I chose urcu-mb, which is the least invasive implementation even though it does not have the fastest rcu_read_{lock,unlock} implementation. The urcu flavor can be changed later, after benchmarking. Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
OpenPOWER on IntegriCloud