gfapi: Fix a deadlock caused by graph switch while aio in progress

RCA:
Currently async nature is achieved by submitting a syncop operation to
synctask threads. Consider a scenario where the graph switch is triggered,
the next write fop checks for the next available graph and sets
fs->migration_in_progess and triggers the migration of fds and other
things, which can cause some syncop_lookup operation. While this fop (on
synctask thread) is waiting for syncop_lookup to return, lets say there
are another 17 write async calls submitted, all these writes are blocked
waiting for fs->migration_in_progress to be unset, hence all the 16
synctask threads are blocked waiting for fs->migration_in_progress to be
unset. Now the syncop_lookup returns, but there are no synctask threads to
process the lookup_cbk. If this syncop_lookup doesn't return,
then fs->migration_in_progress can not be unset by the first fop.
Thus causing a deadlock.

To fix this deadlock, changing all the async APIs to use STACK_WIND,
instead of syntask to achieve async nature. glfs_preadv_async is already
implemented using STACK_WIND, now changing all the other async APIs
also to do the same.

This patch as such will not reduce the performance of async IO, the only
thing that can affect is that, in case of write, the buf passed by
application is copied onto iobuf in the same thread wheras before it
was being copied in synctask thread.

Since, the syncop + graph switch logic (lock across fops) is not a good
candidate for synctask, changing the async APIs to use STACK_WIND

Backport of http://review.gluster.org/#/c/14148/

Change-Id: Idf665cae0a8e27697fbfc5ec8d93a6d6bae3a4f1
BUG: 1333268
Signed-off-by: Poornima G <pgurusid@redhat.com>
Reviewed-on: http://review.gluster.org/14223
Smoke: Gluster Build System <jenkins@build.gluster.com>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra Talur <rtalur@redhat.com>
Reviewed-by: Rajesh Joseph <rjoseph@redhat.com>
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>

0 files changed, 0 insertions, 0 deletions