diff options
| author | Rajesh Joseph <rjoseph@redhat.com> | 2016-11-22 22:25:42 +0530 | 
|---|---|---|
| committer | Niels de Vos <ndevos@redhat.com> | 2016-11-29 23:52:42 -0800 | 
| commit | 17d10b42fc4041442e6cd0bfda45944edea498c6 (patch) | |
| tree | 60abd1b7b5ad506e2b8d5455431188c4d6a08b5f /api/src/glfs-internal.h | |
| parent | e34a783557e504f0793f18beb850bcebbb2af7fa (diff) | |
gfapi: glfs_subvol_done should NOT wait for graph migration.
In graph_setup function glfs_subvol_done is called which
is executed in an epoll thread. glfs_lock waits on other
thread to finish graph migration. This can lead to dead lock
if we consume all the epoll threads.
In general any call-back function executed in epoll thread
should not call any blocking call which waits on a network
reply either directly or indirectly, e.g. syncop functions
should not be called in these threads.
As a fix we should not wait for migration in the call-back path.
Change-Id: If96d0689fe1b4d74631e383048cdc30b01690dc2
BUG: 1397754
Signed-off-by: Rajesh Joseph <rjoseph@redhat.com>
Reviewed-on: http://review.gluster.org/15913
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
Smoke: Gluster Build System <jenkins@build.gluster.org>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
Diffstat (limited to 'api/src/glfs-internal.h')
| -rw-r--r-- | api/src/glfs-internal.h | 15 | 
1 files changed, 12 insertions, 3 deletions
diff --git a/api/src/glfs-internal.h b/api/src/glfs-internal.h index fc62bbf027d..a42822420ea 100644 --- a/api/src/glfs-internal.h +++ b/api/src/glfs-internal.h @@ -305,17 +305,26 @@ do {                                                                \    we can give up the mutex during syncop calls so    that bottom up calls (particularly CHILD_UP notify)    can do a mutex_lock() on @glfs without deadlocking -  the filesystem +  the filesystem. + +  All the fops should wait for graph migration to finish +  before starting the fops. Therefore these functions should +  call glfs_lock with wait_for_migration as true. But waiting +  for migration to finish in call-back path can result thread +  dead-locks. The reason for this is we only have finite +  number of epoll threads. so if we wait on epoll threads +  there will not be any thread left to handle outstanding +  rpc replies.  */  static inline int -glfs_lock (struct glfs *fs) +glfs_lock (struct glfs *fs, gf_boolean_t wait_for_migration)  {  	pthread_mutex_lock (&fs->mutex);  	while (!fs->init)  		pthread_cond_wait (&fs->cond, &fs->mutex); -	while (fs->migration_in_progress) +        while (wait_for_migration && fs->migration_in_progress)  		pthread_cond_wait (&fs->cond, &fs->mutex);  	return 0;  | 
