[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v8 13/21] main: keep rcu_atfork callback enabled for qtest

From: Paolo Bonzini
Subject: Re: [PATCH v8 13/21] main: keep rcu_atfork callback enabled for qtest
Date: Thu, 30 Jan 2020 18:24:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

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

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)?


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]