Introduce MDS_TRAVERSE_XLOCK_DENTRY, which instructs
MDCache::path_traverse() to take appropriate locks (xlock dentry,
wrlock directory's filelock/nestlock) for file create/deletion.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

The helper function is for requests that operate on two paths. It
ensures that the two paths get locks in proper order. The rule is:

 1. Lock directory inodes or dentries according to which trees they
    are under. Lock objects under fs root before objects under mdsdir.
 2. Lock directory inodes or dentries according to their depth, in
    ascending order.
 3. Lock directory inodes or dentries according to inode numbers or
    dentries' parent inode numbers, in ascending order.
 4. Lock dentries in the same directory in order of their keys.
 5. Lock non-directory inodes according to inode numbers, in ascending
    order.

This patch also makes handle_client_link() and handle_client_rename()
to use this helper function.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

If an inode's snaplock is locked by a MDRequest, the inode can not be
renamed by other MDRequest. For rename case, snaplocks of all inodes
in paths are locked. So the paths are stable while handling slave rename.
It's OK to discover all components (even they are xlocked) in the paths.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

MDS now relies on snaplocks to ensure that paths for slave request are
stable. MDCache::handle_find_ino_reply() may encounter xlocked dentry
during path traverse.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Take snap rdlocks (instead of taking dentry locks) on subtree's ancestor
inodes. Path to subtree is stable after they are all locked.

For dirfragtree locks on subtree bounds, it's not convenient to rdlock
them in top-down order (paths to them are not stable). The solution is
kicking them to SYNC state and try taking rdlocks on all of them.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

The lock cache preserves locks and authpins required for directory
operations. MDS can create a lock cache when it has acquired all locks
of a directory operation. The lock cache can be used to for later
operations of the same type on the same directory.

For example, when mds has acquired all locks of a unlink operation,
it creates a lock cache, which holds holds wrlocks on direcotry inode's
filelock and nestlock, rdlocks on ancestor inodes' snaplocks. For later
unlink operations on the same directory, MDS only needs to xlock the
dentry to unlink and xlock linklock of the inode to unlink.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Add a list to SimpleLock, which tracks lock caches which hold locks
on SimpleLock itself. When mds want to change lock state, it can find
lock caches and invalidate them.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Add a list to CDir, which tracks lock caches which hold auth pins on
objects in the CDir. When mds want to freeze dirfrag or subtree, it can
find lock caches and invalidate them

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Frozen inode in directory with lock caches may cause ABBA deadlock. The
requeset that owns the frozen inode can't get locks because lock cache
is holding conflicting locks. The request that uses lock cache can't
auth pin the frozen inode.

The solution is not creating lock cache when directory contains freezing
or frozen inode. When mds starts freezing an inode, invalidate all lock
caches on its parent directory.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Define cap bits for async dir operation. Lock cache for a given type of
dir operation can be delegeted to client through cap mechanism. As long
as client holds correspondindg cap, dir operation requests from the
client can use the lock cache. If mds want to invalidate a lock cache,
it needs to first revoke corresponding cap from client.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

later patch will introduce new mask bits

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

when client has 'CEPH_CAP_FILE_EXCL|CEPH_CAP_DIR_UNLINK' caps of a
directory inode, it can asynchronously unlink file from the directory
if the corresponding dentry is a primary link.

when client has 'CEPH_CAP_FILE_EXCL|CEPH_CAP_DIR_CREATE' caps of a
directory inode, it can asynchronously create new file in the directory
as long as no file with the same name exists.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>

Previous commit makes Server::rdlock_path_pin_ref() rdlock snaplock and
policylock. Deadlock happens if we use this function for requests that
xlock snaplock or snaplock.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>