Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba3ff12fca318225cb978c6181b83d38dcbc5b09
Commit:     ba3ff12fca318225cb978c6181b83d38dcbc5b09
Parent:     ef8142a525c58dec325e8dd9a7bf92fb240d05c7
Author:     Michael Halcrow <[EMAIL PROTECTED]>
AuthorDate: Fri Dec 22 01:08:43 2006 -0800
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Fri Dec 22 08:55:48 2006 -0800

    [PATCH] fsstack: Remove inode copy
    
    Trevor found a file size problem in eCryptfs in recent kernels, and he
    tracked it down to an fsstack change.
    
    This was the eCryptfs copy_attr_all:
    
    > -void ecryptfs_copy_attr_all(struct inode *dest, const struct inode *src)
    > -{
    > -       dest->i_mode = src->i_mode;
    > -       dest->i_nlink = src->i_nlink;
    > -       dest->i_uid = src->i_uid;
    > -       dest->i_gid = src->i_gid;
    > -       dest->i_rdev = src->i_rdev;
    > -       dest->i_atime = src->i_atime;
    > -       dest->i_mtime = src->i_mtime;
    > -       dest->i_ctime = src->i_ctime;
    > -       dest->i_blkbits = src->i_blkbits;
    > -       dest->i_flags = src->i_flags;
    > -}
    
    This is the fsstack copy_attr_all:
    
    > +void fsstack_copy_attr_all(struct inode *dest, const struct inode *src,
    > +                               int (*get_nlinks)(struct inode *))
    > +{
    > +       if (!get_nlinks)
    > +               dest->i_nlink = src->i_nlink;
    > +       else
    > +               dest->i_nlink = (*get_nlinks)(dest);
    > +
    > +       dest->i_mode = src->i_mode;
    > +       dest->i_uid = src->i_uid;
    > +       dest->i_gid = src->i_gid;
    > +       dest->i_rdev = src->i_rdev;
    > +       dest->i_atime = src->i_atime;
    > +       dest->i_mtime = src->i_mtime;
    > +       dest->i_ctime = src->i_ctime;
    > +       dest->i_blkbits = src->i_blkbits;
    > +       dest->i_flags = src->i_flags;
    > +
    > +       fsstack_copy_inode_size(dest, src);
    > +}
    
    The addition of copy_inode_size breaks eCryptfs, since eCryptfs needs to
    interpolate the file sizes (eCryptfs has extra space in the lower file for
    the header).  The setting of the upper inode size occurs elsewhere in
    eCryptfs, and the new copy_attr_all now undoes what eCryptfs was doing
    right beforehand.
    
    I see three ways of going forward from here.  (1) Something like this patch
    needs to go in (assuming it jives with Unionfs), (2) we need to make a
    change to the fsstack API for more fine-grained control over copying
    attributes (e.g., by also including a callback function for calculating the
    right file size, which will require some more work on both eCryptfs and
    Unionfs), or (3) the fsstack patch on eCryptfs (commit
    0cc72dc7f050188d8d7344b1dd688cbc68d3cd30 made on Fri Dec 8 02:36:31 2006
    -0800) needs to be yanked in 2.6.20.
    
    I think the simplest solution, from eCryptfs' perspective, is to just
    remove the inode size copy.
    
    Remove inode size copy in general fsstack attr copy code. Stacked
    filesystems may need to interpolate the inode size, since the file
    size in the lower file may be different than the file size in the
    stacked layer.
    
    Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
    Acked-by: Josef "Jeff" Sipek <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
 fs/stack.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/fs/stack.c b/fs/stack.c
index 5ddbc34..8ffb880 100644
--- a/fs/stack.c
+++ b/fs/stack.c
@@ -34,7 +34,5 @@ void fsstack_copy_attr_all(struct inode *dest, const struct 
inode *src,
        dest->i_ctime = src->i_ctime;
        dest->i_blkbits = src->i_blkbits;
        dest->i_flags = src->i_flags;
-
-       fsstack_copy_inode_size(dest, src);
 }
 EXPORT_SYMBOL_GPL(fsstack_copy_attr_all);
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to