protocol/client: Do not fallback to anon-fd if fd is not open

If an open comes on a file when a brick is down and after the brick comes up,
a fop comes on the fd, client xlator would still wind the fop on anon-fd
leading to wrong behavior of the fops in some cases.

Example:
If lk fop is issued on the fd just after the brick is up in the scenario above,
lk fop will be sent on anon-fd instead of failing it on that client xlator.
This lock will never be freed upon close of the fd as flush on anon-fd is
invalid and is not wound below server xlator.

As a fix, failing the fop unless the fd has FALLBACK_TO_ANON_FD flag.

Change-Id: I77692d056660b2858e323bdabdfe0a381807cccc
fixes bz#1390914
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>

1 files changed, 7 insertions, 1 deletions

diff --git a/xlators/protocol/client/src/client-helpers.c b/xlators/protocol/client/src/client-helpers.c
index 24f0cfa6137..53b4484ecc8 100644
--- a/xlators/protocol/client/src/client-helpers.c
+++ b/xlators/protocol/client/src/client-helpers.c
@@ -419,7 +419,13 @@ client_get_remote_fd(xlator_t *this, fd_t *fd, int flags, int64_t *remote_fd)
     {
         fdctx = this_fd_get_ctx(fd, this);
         if (!fdctx) {
-            *remote_fd = GF_ANON_FD_NO;
+            if (fd->anonymous) {
+                *remote_fd = GF_ANON_FD_NO;
+            } else {
+                *remote_fd = -1;
+                gf_msg_debug(this->name, EBADF, "not a valid fd for gfid: %s",
+                             uuid_utoa(fd->inode->gfid));
+            }
         } else {
             if (__is_fd_reopen_in_progress(fdctx))
                 *remote_fd = -1;