libglusterfsclient: Sync access to VMP list on new entry addition

Some weeks back, I'd separated the big lock into vmplock and mountlock.
See commit 304e4274ca9b0339539581c5413e3339078c1182 in mainline.

At that time, we did not have a solution to the problem
of when to init the vmplist in a thread-safe manner, since
there was no lock to protect the vmplock specifically, and that
when libgf_vmp_map_ghandle was called inside glusterfs_mount
so the "lock" was already being held.

Now that we have separate mount and vmp locks, the
accesses can be synced correctly.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

BUG: 211 (libglusterfsclient: Race condition against vmplist in libgf_vmp_map_ghandle)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=211

1 files changed, 9 insertions, 9 deletions

diff --git a/libglusterfsclient/src/libglusterfsclient.c b/libglusterfsclient/src/libglusterfsclient.c
index c690bbba4..1ce94b8fd 100755
--- a/libglusterfsclient/src/libglusterfsclient.c
+++ b/libglusterfsclient/src/libglusterfsclient.c
@@ -1514,16 +1514,16 @@ libgf_vmp_map_ghandle (char *vmp, glusterfs_handle_t *vmphandle)
         if (!vmpentry)
                 goto out;
 
-        /* 
-           FIXME: this is not thread-safe, but I couldn't find other place to
-           do initialization.
-        */ 
-        if (vmplist.entries == 0) {
-                INIT_LIST_HEAD (&vmplist.list);
-        }
+        pthread_mutex_lock (&vmplock);
+        {
+                if (vmplist.entries == 0) {
+                        INIT_LIST_HEAD (&vmplist.list);
+                }
 
-        list_add_tail (&vmpentry->list, &vmplist.list);
-        ++vmplist.entries;
+                list_add_tail (&vmpentry->list, &vmplist.list);
+                ++vmplist.entries;
+        }
+        pthread_mutex_unlock (&vmplock);
         ret = 0;
 
 out: