[Gluster-devel] spurious failure with sparse-file-heal.t test

Krishnan Parthasarathi kparthas at redhat.com
Fri Jun 5 03:40:05 UTC 2015



----- Original Message -----
> 
> > This seems to happen because of race between STACK_RESET and stack
> > statedump. Still thinking how to fix it without taking locks around
> > writing to file.
> 
> Why should we still keep the stack being reset as part of pending pool of
> frames? Even we if we had to (can't guess why?), when we remove we should do
> the following to prevent gf_proc_dump_pending_frames from crashing.
> 
> ...
> 
> call_frame_t *toreset = NULL;
> 
> LOCK (&stack->pool->lock)
> {
>   toreset = stack->frames;
>   stack->frames = NULL;
> }
> UNLOCK (&stack->pool->lock);
> 
> ...
> 
> Now, perform all operations that are done on stack->frames on toreset
> instead. Thoughts?

Is there a reason you want to avoid locks here? STACK_DESTROY uses the
call_pool lock to remove the stack from the list of pending frames.

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 


More information about the Gluster-devel mailing list