andy/glusterfs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fuse: protect checking/modifying graph->used with a mutex

Browse Source 
While reviewing http://review.gluster.org/#/c/9060/ we noticed that fuse
checks/modifies graph->used in a unlocked way. There is a potential race
in case when fuse_graph_setup() gets called from two different threads
(currently  unlikely, but poller/notify() might change in future?).

In libgfapi we came to the conclusion that each glfs structure can be
used to protect the checking/updating of graph->used. In fuse this would
be the fuse_private_t with sync_mutex.

BUG: 1170643
Change-Id: If5ab5468d22fdb92cfb24a469f538f63f12baf78
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/9237
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
This commit is contained in:
Niels de Vos 2014-12-04 15:40:52 +01:00
parent 12c15f47fe
commit 09af313fe6
1 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xlators/mount/fuse/src/fuse-bridge.c
View File

@ -5032,10 +5032,16 @@ fuse_graph_setup (xlator_t *this, glusterfs_graph_t *graph)
if (priv->active_subvol == graph->top)
return 0; /* This is a valid case */
if (graph->used)
return 0;
pthread_mutex_lock (&priv->sync_mutex);
{
if (graph->used) {
pthread_mutex_unlock (&priv->sync_mutex);
return 0;
}
graph->used = 1;
graph->used = 1;
}
pthread_mutex_unlock (&priv->sync_mutex);
itable = inode_table_new (0, graph->top);
if (!itable)