Re: [Qemu-devel] [PATCH v9 04/10] replay: fix processing async events

["Pavel Dovgalyuk" <dovgaluk@ispras.ru>]

> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> On 04/05/2017 10:41, Pavel Dovgalyuk wrote:
> > From: Pavel Dovgalyuk <Pavel.Dovgaluk@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.dovgaluk@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