[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] [GFS2 PATCH] GFS2: Eliminate sd_rindex_mutex


On Mon, 2012-03-05 at 08:33 -0500, Bob Peterson wrote:
> ----- Original Message -----
> | Bearing in mind that the mutex is an exclusive lock and the glock is
> | only a shared lock, do we have any other protection against the rgrp
> | tree being updated simultaneously?
> | 
> | Steve.
> Hi,
> Yes, I think you're right. The existing code should work most of the
> time but has the potential to leak rgrp memory if the timing is right.
> We could approach the solution two ways:
> (1) We could change the shared lock to an exclusive lock.
That is not a good solution. Think about what happens when we have
multiple nodes, and grow has just finished on one... we want them all to
be able to update at the same time.

> (2) We could change function rgd_insert so that it returns an error if
>     the rgrp was already in the rb_tree. That way, whoever gets the
>     sd_rindex_spin spinlock first will call rgd_insert to insert the new
>     rgrp into the rgrp tree, and when the second caller tries to insert
>     its new rgrp into the rb_tree, it will find the entry already there,
>     (inserted by the first caller), then take the error path and exit,
>     freeing the rgrp it kmalloced.
> Regards,
> Bob Peterson
> Red Hat File Systems

Yes, thats ok since we know that the rgrps will only grow and never
shrink, so if we find one already inserted, we know that we raced and
can free the new entry rather than adding it,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]