[v9,04/10] replay: fix processing async events

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(-)

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.

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.

I think it is worth fixing all of these.

Paolo

>      }
>  }
>  
>

> 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