From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJftY-0005TW-C6 for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:44:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJftT-0007rw-D3 for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:44:32 -0400 Received: from [59.151.112.132] (port=34940 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJftS-0007qS-PE for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:44:27 -0400 References: <55B59652.4090503@cn.fujitsu.com> <55B60536.4090006@redhat.com> From: Wen Congyang Message-ID: <55B60B8A.3040703@cn.fujitsu.com> Date: Mon, 27 Jul 2015 18:44:26 +0800 MIME-Version: 1.0 In-Reply-To: <55B60536.4090006@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.5] rcu: Allow calling rcu_(un)register_thread() during synchronize_rcu() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devl On 07/27/2015 06:17 PM, Paolo Bonzini wrote: > > > On 27/07/2015 04:24, Wen Congyang wrote: >> + /* Wait for one thread to report a quiescent state and try again. >> + * Release rcu_registry_lock, so rcu_(un)register_thread() doesn't >> + * wait too much time. Note: rcu_unregister_thread() may remove >> + * the node from qsreaders. That's a bit tricky, but it should work. > > "It should work" is a bit optimistic. :D > > Does this description look okay? > > /* Wait for one thread to report a quiescent state and try again. > * Release rcu_registry_lock, so rcu_(un)register_thread() doesn't > * wait too much time. > * > * rcu_register_thread() may add nodes to ®istry; it will not > * wake up synchronize_rcu, but that is okay because at least another > * thread must exit its RCU read-side critical section before > * synchronize_rcu is done. The next iteration of the loop will > * process the new thread or set ->waiting for it. Hence, this can > * at worst cause synchronize_rcu() to wait for longer. I don't understand this. The next iteration of the loop will move the new thread's rcu_reader from registry to qsreaders even if we call rcu_read_lock() in the new thread. Because rcu_gp_ongoing() will return false. Thanks Wen Congyang > * > * rcu_unregister_thread() may remove nodes from &qsreaders instead > * of ®istry if it runs during qemu_event_wait. That's okay; > * the node then will not be added back to ®istry by QLIST_SWAP > * below. The invariant is that the node is part of one list when > * rcu_registry_lock is released. > */ > > Paolo > . >