client-protocol: fix race-condition encountered while accessing fdctx

- In protocol/client, fdctx is accessed by two sets of procedures,
  protocol_client_mark_fd_bad falls in one set whereas the other set consists of
  all fops which receive fd as an argument. The way these fdctxs are got is
  different in these two sets. While in the former set, fdctx is accessed
  through conf->saved_fds, which is a list of fdctxs of fds representing
  opened/created files. In the latter set, fdctxs are got directly from fd
  through fd_ctx_get(). Now there can be race conditions between two threads
  executing one procedure from these two sets. As an example let us consider
  following scenario:

  A flush operation is timed out and polling thread executing
  protocol_client_mark_fd_bad, fuse thread executing client_release. This can
  happen because, immediately a reply for flush is written to fuse, a release on
  the same fd can be sent to glusterfs and the polling thread still might be
  doing cleanup. Consider following set of events:

  1. fuse thread does fd_ctx_get (fd).
  2. polling thread gets the same fdctx but through conf->saved_fds.
  3. Now both threads go ahead and does list_del (fdctx) and eventually free
     fdctx.

  In other situations the same set events might occur and the threads
  executing fops other than flush in the second set might be accessing a
  fdctx freed in protocol_client_mark_fd_bad.

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

BUG: 127 (race-condition in accessing fdctx in protocol/client)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=127

0 files changed, 0 insertions, 0 deletions