From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD6v2-00071T-Gz for qemu-devel@nongnu.org; Thu, 09 Jul 2015 04:10:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZD6uz-0007M5-3f for qemu-devel@nongnu.org; Thu, 09 Jul 2015 04:10:56 -0400 Received: from [59.151.112.132] (port=56124 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD6uy-0007Jd-OQ for qemu-devel@nongnu.org; Thu, 09 Jul 2015 04:10:53 -0400 Message-ID: <559E2D57.4020204@cn.fujitsu.com> Date: Thu, 9 Jul 2015 16:14:15 +0800 From: Wen Congyang MIME-Version: 1.0 References: <1436274549-28826-1-git-send-email-quintela@redhat.com> <1436274549-28826-28-git-send-email-quintela@redhat.com> <20150708191318.GM4117@noname.redhat.com> <559D89AD.4090000@redhat.com> <559DCC2A.1040400@cn.fujitsu.com> <559E29E5.5000402@redhat.com> In-Reply-To: <559E29E5.5000402@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 27/28] migration: protect migration_bitmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Kevin Wolf , Juan Quintela Cc: amit.shah@redhat.com, qemu-devel@nongnu.org, Li Zhijian On 07/09/2015 03:59 PM, Paolo Bonzini wrote: > > > On 09/07/2015 03:19, Wen Congyang wrote: >> Yes, why migration doesn't trigger this problem? We will fix it soon. > > This should be the fix if someone wants to test it and/or post it: > > diff --git a/migration/ram.c b/migration/ram.c > index 57368e1..8d5a73a 100644 > --- a/migration/ram.c > +++ b/migration/ram.c > @@ -1227,9 +1227,9 @@ static int ram_save_complete(QEMUFile *f, void > *opaque) > > flush_compressed_data(f); > ram_control_after_iterate(f, RAM_CONTROL_FINISH); > - migration_end(); > - > rcu_read_unlock(); > + > + migration_end(); > qemu_put_be64(f, RAM_SAVE_FLAG_EOS); Yes, this patch can work. But if the caller hold the rcu read lock in the future, we may need to fix it again. I think it is better to use call_rcu(). > > return 0; > > > You don't see it with migration because the migration thread (and for > that matter, _no_ thread except the I/O thread!) is not registered with > the RCU subsystem. I'm working on it, but I plan to only fix it in > later release candidates. Thanks for the explantion. Wen Congyang > > Paolo >