[Bugs] [Bug 1610256] [Ganesha] While performing lookups from two of the clients, "ls" command got failed with "Invalid argument"

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1610256

Worker Ant <bugzilla-bot at gluster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|POST                        |MODIFIED



--- Comment #3 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/20643 committed in master by "Atin
Mukherjee" <amukherj at redhat.com> with a commit message- cluster/dht: fix inode
ref management in dht_heal_path

In dht_heal_path, the inodes are created & looked up from top to down.

If the path is "a/b/c", then lookup will be done on a, then b and so
on. Here is a rough snippet of the function "dht_heal_path".

<snippet>
if (bname) {                        ref_count
    - loc.inode = create/grep inode              1
    - syncop_lookup (loc.inode)
    - linked_inode = inode_link (loc.inode)          2
    /*clean up current loc*/
    - loc_wipe(&loc)                  1
    /*set up parent and bname for next child */
    - loc.parent = inode
    - bname = next_child_name
}
out:
    - inode_ref (linked_inode)              2
    - loc_wipe (&loc)                   1
</snippet>

The problem with the above code is if _bname_ is empty ie the chain lookup is
done, then for the next iteration we populate loc.parent anyway. Now that
bname is empty, the loc_wipe is done in the _out_ section as well. Since, the
loc.parent was set to the previous inode, we lose a ref unwantedly. Now a
dht_local_wipe as part of the DHT_STACK_UNWIND takes away the last ref leading
to inode_destroy.

This problenm is observed currently with nfs-ganesha with the nameless lookup.
Post the inode_purge, gfapi does not get the new inode to link and hence, it
links
the inode it sent in the lookup fop, which does not have any dht related
context
(layout) leading to "invalid argument error" in lookup path done parallely with
tar
operation.

test done in the following way:
 - create two nfs client connected with two different nfs servers.
 - run untar on one client and run lookup continuously on the other.
 - Prior to this patch, invalid arguement was seen which is fixed with
   the current patch.

Change-Id: Ifb90c178a2f3c16604068c7da8fa562b877f5c61
fixes: bz#1610256
Signed-off-by: Susant Palai <spalai at redhat.com>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.