| Message ID | 559E29E5.5000402@redhat.com |
|---|---|
| State | New |
| Headers | show |
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 >
On 09/07/2015 10:14, Wen Congyang wrote: > > 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(). Why? Just document that migration_end must be called outside an RCU read-side critical section. It's not a heavy limitation. Paolo
At 2015/7/9 20:51, Paolo Bonzini Wrote: > > > On 09/07/2015 10:14, Wen Congyang wrote: >>> 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(). > > Why? Just document that migration_end must be called outside an RCU > read-side critical section. It's not a heavy limitation. > If so, it is OK Thanks Wen Congyang > Paolo > >
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);
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: 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. Paolo