> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > On 04/05/2017 10:41, Pavel Dovgalyuk wrote: > > From: Pavel Dovgalyuk <pavel.dovga...@ispras.ru> > > > > Asynchronous events saved at checkpoints may invoke > > callbacks when processed. These callbacks may also generate/read > > new events (e.g. clock reads). Therefore event processing flag must be > > reset before callback invocation. > > > > Signed-off-by: Pavel Dovgalyuk <pavel.dovga...@ispras.ru> > > --- > > replay/replay-events.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/replay/replay-events.c b/replay/replay-events.c > > index 94a6dcccfc..768b505f3d 100644 > > --- a/replay/replay-events.c > > +++ b/replay/replay-events.c > > @@ -295,13 +295,13 @@ void replay_read_events(int checkpoint) > > if (!event) { > > break; > > } > > + replay_finish_event(); > > + read_event_kind = -1; > > replay_mutex_unlock(); > > replay_run_event(event); > > replay_mutex_lock(); > > > > g_free(event); > > - replay_finish_event(); > > - read_event_kind = -1; > > While at it, g_free can be moved outside the lock.
There is no difference where to free the memory. The only reason for unlocking and locking again is that replay_run_event may try to read more data from the log. > Also, replay_flush_events and replay_save_events are leaving the event > in events_list while releasing the lock, and only doing QTAILQ_REMOVE > after taking it back. This can cause events to be processed twice. How this could happen? If something will try to call replay_save_events again, while in replay_save_events, then we'll have an infinite loop and notice it. But it couldn't, because saving only occurs at checkpoints and there are no recursive ones. Pavel Dovgalyuk
