This is a note to let you know that I've just added the patch titled

    eCryptfs: Copy up lower inode attrs in getattr

to the 2.6.32-longterm tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary

The filename of the patch is:
     ecryptfs-copy-up-lower-inode-attrs-in-getattr.patch
and it can be found in the queue-2.6.32 subdirectory.

If you, or anyone else, feels it should not be added to the 2.6.32 longterm 
tree,
please let <[email protected]> know about it.


>From 55f9cf6bbaa682958a7dd2755f883b768270c3ce Mon Sep 17 00:00:00 2001
From: Tyler Hicks <[email protected]>
Date: Tue, 11 Jan 2011 12:43:42 -0600
Subject: eCryptfs: Copy up lower inode attrs in getattr

From: Tyler Hicks <[email protected]>

commit 55f9cf6bbaa682958a7dd2755f883b768270c3ce upstream.

The lower filesystem may do some type of inode revalidation during a
getattr call. eCryptfs should take advantage of that by copying the
lower inode attributes to the eCryptfs inode after a call to
vfs_getattr() on the lower inode.

I originally wrote this fix while working on eCryptfs on nfsv3 support,
but discovered it also fixed an eCryptfs on ext4 nanosecond timestamp
bug that was reported.

https://bugs.launchpad.net/bugs/613873

Signed-off-by: Tyler Hicks <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 fs/ecryptfs/inode.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -988,6 +988,8 @@ int ecryptfs_getattr(struct vfsmount *mn
        rc = vfs_getattr(ecryptfs_dentry_to_lower_mnt(dentry),
                         ecryptfs_dentry_to_lower(dentry), &lower_stat);
        if (!rc) {
+               fsstack_copy_attr_all(dentry->d_inode,
+                                     ecryptfs_inode_to_lower(dentry->d_inode), 
NULL);
                generic_fillattr(dentry->d_inode, stat);
                stat->blocks = lower_stat.blocks;
        }


Patches currently in longterm-queue-2.6.32 which might be from 
[email protected] are

_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable

Reply via email to