From c2caeffbc6e1a3b9cb43237ecac105008561e8d6 Mon Sep 17 00:00:00 2001 From: Shehjar Tikoo Date: Thu, 13 Aug 2009 02:56:18 +0000 Subject: 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 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 --- libglusterfsclient/src/libglusterfsclient.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'libglusterfsclient/src/libglusterfsclient.c') 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: -- cgit