From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37677)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1ZJg35-0000H4-SK
	for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:54:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1ZJg30-00041C-TS
	for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:54:23 -0400
Received: from [59.151.112.132] (port=55253 helo=heian.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1ZJg30-00040o-7P
	for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:54:18 -0400
References: <55B59652.4090503@cn.fujitsu.com> <55B60536.4090006@redhat.com>
	<55B60B8A.3040703@cn.fujitsu.com> <55B60D7C.4050100@redhat.com>
From: Wen Congyang <wency@cn.fujitsu.com>
Message-ID: <55B60DD8.4020708@cn.fujitsu.com>
Date: Mon, 27 Jul 2015 18:54:16 +0800
MIME-Version: 1.0
In-Reply-To: <55B60D7C.4050100@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devl <qemu-devel@nongnu.org>

On 07/27/2015 06:52 PM, Paolo Bonzini wrote:
> 
> 
> On 27/07/2015 12:44, Wen Congyang wrote:
>>>          * rcu_register_thread() may add nodes to &registry; 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.
> 
> You're right.  This proves that a comment was necessary! :)

Yes, I agree with it.

> 
> Second try:
> 
>      * rcu_register_thread() may add nodes to &registry; 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
>      * move the new thread's rcu_reader from &registry to &qsreaders,
>      * because rcu_gp_ongoing() will return false.

I will update the comment and send it again.

Thanks
Wen Congyang

> 
> Paolo
> .
>