From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKFu3-0005We-Vo for qemu-devel@nongnu.org; Tue, 28 Jul 2015 21:11:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKFu0-0004S2-Ot for qemu-devel@nongnu.org; Tue, 28 Jul 2015 21:11:27 -0400 Received: from [59.151.112.132] (port=29834 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKFu0-0004Oz-Dt for qemu-devel@nongnu.org; Tue, 28 Jul 2015 21:11:24 -0400 References: <55B6E854.9090600@cn.fujitsu.com> <55B75278.80909@redhat.com> <55B7532D.9010506@cn.fujitsu.com> <55B756D8.9090503@redhat.com> <55B75A70.8080203@cn.fujitsu.com> <55B76BA3.4080804@redhat.com> <55B783D6.3020102@gmail.com> <55B7AA66.1070209@redhat.com> From: Wen Congyang Message-ID: <55B8283A.2060508@cn.fujitsu.com> Date: Wed, 29 Jul 2015 09:11:22 +0800 MIME-Version: 1.0 In-Reply-To: <55B7AA66.1070209@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 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 , Wen Congyang , qemu-devl On 07/29/2015 12:14 AM, Paolo Bonzini wrote: > > > On 28/07/2015 15:29, Wen Congyang wrote: >>>> >>> >>> If you call it just once, you have the same problem as before. In fact, >>> it's worse because instead of having an overflow every 2^31 periods, you >>> have one every 2 periods. Instead, by checking that rcu_reader went >>> through 1 _and_ 3 (or that it was at least once 0, i.e. the thread was >>> quiescent), you are sure that the thread went through _at least one_ >>> grace period. >> >> The overflow is acceptable. We only compare if rcu_reader.ctr is equal than >> rcu_gp_ctr. If not, we should wait that thread to call rcu_read_unlock(). >> We don't care which is bigger. If no threads calls sync_rcu(), all threads >> rcu_read.ctr is 0 or rcu_gp_ctr. If one thread calls sync_rcu(), all >> threads rcu_read.ctr is 0, old_rcu_gp_ctr, or new_rcu_gp_ctr. We only wait the >> thread that's rcu_read.ctr is old_rcu_gp_ctr. > > Suppose you have > > reader writer > --------------------------------------------------------------- > rcu_read_lock() > ctr = atomic_read(&rcu_gp_ctr); > ctr = 1 > synchronize_rcu() > rcu_gp_ctr = 3 > atomic_xchg(&p_rcu_reader->ctr, ctr); > rcu_reader.ctr = 1 > > We're in the critical section. > > synchronize_rcu() > rcu_gp_ctr = 1 > > rcu_gp_ongoing(&p_rcu_reader->ctr) returns false, so synchronize_rcu() > exits. But we're still in the critical section. > > p = atomic_rcu_read(&foo); > g_free(p); > > Boom. :) For more information see > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.220.8810 Thanks for your explanation. I understand it now. If we use rcu_gp_ctr + RCU_GP_CTR for 32-bit host, the problem only exists when we call synchronize_rcu() 2^31 times while another thread calls rcu_read_lock(). Thanks Wen Congyang > > Paolo >