Because of the changes made in dcache.h header file, files that use
the d_lock and d_count fields of the dentry structure need to be
changed accordingly.  All the d_lock's spin_lock() and spin_unlock()
calls are replaced by the corresponding d_lock() and d_unlock() calls.
References to d_count are replaced by the d_ret_count() calls.
There is no change in logic and everything should just work.

Signed-off-by: Waiman Long <[email protected]>
---
 fs/coda/cache.c |    4 ++--
 fs/coda/dir.c   |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/coda/cache.c b/fs/coda/cache.c
index 1da168c..eb8a625 100644
--- a/fs/coda/cache.c
+++ b/fs/coda/cache.c
@@ -91,13 +91,13 @@ static void coda_flag_children(struct dentry *parent, int 
flag)
 {
        struct dentry *de;
 
-       spin_lock(&parent->d_lock);
+       d_lock(parent);
        list_for_each_entry(de, &parent->d_subdirs, d_u.d_child) {
                /* don't know what to do with negative dentries */
                if (de->d_inode ) 
                        coda_flag_inode(de->d_inode, flag);
        }
-       spin_unlock(&parent->d_lock);
+       d_unlock(parent);
        return; 
 }
 
diff --git a/fs/coda/dir.c b/fs/coda/dir.c
index b7d3a05..162da7b 100644
--- a/fs/coda/dir.c
+++ b/fs/coda/dir.c
@@ -560,7 +560,7 @@ static int coda_dentry_revalidate(struct dentry *de, 
unsigned int flags)
        if (cii->c_flags & C_FLUSH) 
                coda_flag_inode_children(inode, C_FLUSH);
 
-       if (de->d_count > 1)
+       if (d_ret_count(de) > 1)
                /* pretend it's valid, but don't change the flags */
                goto out;
 
@@ -575,7 +575,7 @@ out:
 }
 
 /*
- * This is the callback from dput() when d_count is going to 0.
+ * This is the callback from dput() when d_ret_count() is going to 0.
  * We use this to unhash dentries with bad inodes.
  */
 static int coda_dentry_delete(const struct dentry * dentry)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to