On 30/01/20 15:42, Stefan Hajnoczi wrote: >> + >> + /* >> + * If QTest is enabled, keep the rcu_atfork enabled, since system >> processes >> + * may be forked testing purposes (e.g. fork-server based fuzzing) >> + */ >> + if (!qtest_enabled()) { >> + rcu_disable_atfork(); >> + } > I haven't reviewed the details of whether resources are leaked across > fork but in general it makes sense that we want an RCU thread in the > fork child:
Note that there is a possible deadlock between fork and synchronize_rcu (see commit 73c6e40, "rcu: completely disable pthread_atfork callbacks as soon as possible", 2016-01-27): - the CPU thread is inside a RCU critical section and wants to take the BQL in order to do MMIO - the I/O thread, which is owning the BQL, forks and 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. Therefore it would be best if the fork server could fork before a single CPU instruction is executed, and then rcu_disable_atfork could be moved right after the fork server is started (just like right now we do it right after os_daemonize). We probably talked about this before, but how do you ensure that the fork server is started before threads are created (apart from the RCU thread)? Paolo
signature.asc
Description: OpenPGP digital signature