[Gluster-devel] Behaviour of glfs_fini() affecting QEMU

[Deepak Shetty]

On Thu, Apr 17, 2014 at 6:58 PM, Bharata B Rao <bharata.rao at gmail.com>wrote:

> Hi,
>
> In QEMU, we initialize gfapi in the following manner:
>
> ********************
> glfs = glfs_new();
> if (!glfs)
>    goto out;
> if (glfs_set_volfile_server() < 0)
>    goto out;
> if (glfs_set_logging() < 0)
>    goto out;
> if (glfs_init(glfs))
>    goto out;
>
> ...
>
> out:
> if (glfs)
>    glfs_fini(glfs)
> *********************
>
> Now if either glfs_set_volfile_server() or glfs_set_logging() fails, we
> end up doing glfs_fini() which eventually hangs in glfs_lock().
>
> #0  0x00007ffff554a595 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x00007ffff79d312e in glfs_lock (fs=0x555556331310) at
> glfs-internal.h:176
> #2  0x00007ffff79d5291 in glfs_active_subvol (fs=0x555556331310) at
> glfs-resolve.c:811
> #3  0x00007ffff79c9f23 in glfs_fini (fs=0x555556331310) at glfs.c:753
>
> Note that we haven't done glfs_init() in this failure case.
>
> - Is this failure expected ? If so, what is the recommended way of
> releasing the glfs object ?
> - Does glfs_fini() depend on glfs_init() to have worked successfully ?
>

170 static inline int
171 glfs_lock (struct glfs *fs)
172 {
173         pthread_mutex_lock (&fs->mutex);
174
175         while (!fs->init)
176                 pthread_cond_wait (&fs->cond, &fs->mutex);

The glfs_lock indeed seems to work only when glfs_init is succesfull!
We can call glfs_unset_volfile_server for the error case of
glfs_set_volfile_server as a good practice.
But it does look like we need a opposite of glfs_new (maybe glfs_destroy)
for cases like these to clenaup stuff that glfs_new() allocated

thats my 2 cents... hope to hear from other gluster core folks on this

thanx,
deepak


> - Since QEMU-GlusterFS driver was developed when libgfapi was very new,
> can gluster developers take a look at the order of the glfs_* calls we are
> making in QEMU and suggest any changes, improvements or additions now given
> that libgfapi has seen a lot of development ?
>
> Regards,
> Bharata.
> --
> http://raobharata.wordpress.com/
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140417/2d025e9d/attachment-0001.html>