diff options
| author | Paolo Bonzini | 2016-01-27 08:49:21 +0100 |
|---|---|---|
| committer | Paolo Bonzini | 2017-08-08 10:40:09 +0200 |
| commit | 73c6e4013b4cd92d3d531bc22cc29e6036ef42e0 (patch) | |
| tree | a6eda7dbf2e2dfb39507cefd5cd0cb95cbe8a640 /linux-user | |
| parent | Merge remote-tracking branch 'remotes/yongbok/tags/mips-20170803' into staging (diff) | |
| download | qemu-73c6e4013b4cd92d3d531bc22cc29e6036ef42e0.tar.gz qemu-73c6e4013b4cd92d3d531bc22cc29e6036ef42e0.tar.xz qemu-73c6e4013b4cd92d3d531bc22cc29e6036ef42e0.zip | |
rcu: completely disable pthread_atfork callbacks as soon as possible
Because of -daemonize, system mode QEMU sometimes needs to fork() and
keep RCU enabled in the child. However, there is a possible deadlock
with synchronize_rcu:
- the CPU thread is inside a RCU critical section and wants to take
the BQL in order to do MMIO
- the monitor thread, which is owning the BQL, calls rcu_init_lock
which tries to take the rcu_sync_lock
- the call_rcu thread has taken rcu_sync_lock in synchronize_rcu, but
synchronize_rcu needs the CPU thread to end the critical section
before returning.
This cannot happen for user-mode emulation, because it does not have
a BQL.
To fix it, assume that system mode QEMU only forks in preparation for
exec (except when daemonizing) and disable pthread_atfork as soon as
the double fork has happened.
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>
Diffstat (limited to 'linux-user')
0 files changed, 0 insertions, 0 deletions
