| Message ID | 20100823095056.ACBA.61FB500B@jp.fujitsu.com |
|---|---|
| State | New, archived |
| Headers | show |
On Mon 23-08-10 09:50:56, Masayoshi MIZUMA wrote: > In ext3 filesystem, if following conditions 1., 2., 3. and 4. is satisfied, > getfattr can't search the extended attribute (EA) after remount. > > Condition: > 1. the inode size is over 128 byte > 2. "lost+found" whose inode number is 11 was removed > 3. the 11th inode is used for a file. > 4. the EA locates in-inode > > This happens because of following logic: > i_extra_isize is set to over 0 by ext3_new_inode() when we create > a file whose inode number is 11 after removing "lost+found". > Therefore setfattr creates the EA in-inode. > After remount, i_extra_isize of 11th inode is set to 0 by ext3_iget() > when we lookup the file, so getfattr tries to search the EA out-inode. > However, the EA locates in-inode, so getfattr can't search the EA. > > How to reproduce: > 1. mkfs.ext3 -I 256 /dev/sdXX > 2. mount -o acl,user_xattr /dev/sdXX /TEST > 3. rm -rf /TEST/* > 4. touch /TEST/file (whose inode number is 11) > 5. cd /TEST; setfattr -n user.foo0 -v bar0 file > 6. cd /TEST; getfattr -d file > -> can see foo0/bar0 > 7. umount /dev/sdXX > 8. mount -o acl,user_xattr /dev/sdXX /TEST > 9. cd /TEST; getfattr -d file > -> can't see foo0/bar0 > > Though the 11th inode is used for "lost+found" normally, the other > file can also use it. Therefore, i_extra_isize of 11th inode should be set > to the suitable value by ext3_iget(). Hmm, with which kernel have you tested that? Because my 2.6.32 kernel works just fine (and looking into the code, all should be handled well). Look: mount -o loop,user_xattr ~jack/fs-images/ext3-image /mnt/ quack:/crypted/home/jack # cd /mnt/ quack:/mnt # touch file quack:/mnt # ls -i file 11 file quack:/mnt # setfattr -n user.foo0 -v bar0 file quack:/mnt # getfattr -d file # file: file user.foo0="bar0" quack:/mnt # cd quack:~ # umount /mnt quack:~ # mount -o loop,user_xattr ~jack/fs-images/ext3-image /mnt/ quack:~ # getfattr -d /mnt/file getfattr: Removing leading '/' from absolute path names # file: mnt/file user.foo0="bar0" Honza
On Tue, 24 Aug 2010 15:17:36 +0200 Jan Kara <jack@suse.cz> wrote: > On Mon 23-08-10 09:50:56, Masayoshi MIZUMA wrote: > > In ext3 filesystem, if following conditions 1., 2., 3. and 4. is satisfied, > > getfattr can't search the extended attribute (EA) after remount. > > > > Condition: > > 1. the inode size is over 128 byte > > 2. "lost+found" whose inode number is 11 was removed > > 3. the 11th inode is used for a file. > > 4. the EA locates in-inode > > > > This happens because of following logic: > > i_extra_isize is set to over 0 by ext3_new_inode() when we create > > a file whose inode number is 11 after removing "lost+found". > > Therefore setfattr creates the EA in-inode. > > After remount, i_extra_isize of 11th inode is set to 0 by ext3_iget() > > when we lookup the file, so getfattr tries to search the EA out-inode. > > However, the EA locates in-inode, so getfattr can't search the EA. > > > > How to reproduce: > > 1. mkfs.ext3 -I 256 /dev/sdXX > > 2. mount -o acl,user_xattr /dev/sdXX /TEST > > 3. rm -rf /TEST/* > > 4. touch /TEST/file (whose inode number is 11) > > 5. cd /TEST; setfattr -n user.foo0 -v bar0 file > > 6. cd /TEST; getfattr -d file > > -> can see foo0/bar0 > > 7. umount /dev/sdXX > > 8. mount -o acl,user_xattr /dev/sdXX /TEST > > 9. cd /TEST; getfattr -d file > > -> can't see foo0/bar0 > > > > Though the 11th inode is used for "lost+found" normally, the other > > file can also use it. Therefore, i_extra_isize of 11th inode should be set > > to the suitable value by ext3_iget(). > Hmm, with which kernel have you tested that? Because my 2.6.32 kernel > works just fine (and looking into the code, all should be handled well). I tested at 2.6.35. > Look: > mount -o loop,user_xattr ~jack/fs-images/ext3-image /mnt/ > quack:/crypted/home/jack # cd /mnt/ > quack:/mnt # touch file > quack:/mnt # ls -i file > 11 file > quack:/mnt # setfattr -n user.foo0 -v bar0 file > quack:/mnt # getfattr -d file > # file: file > user.foo0="bar0" > > quack:/mnt # cd > quack:~ # umount /mnt > quack:~ # mount -o loop,user_xattr ~jack/fs-images/ext3-image /mnt/ > quack:~ # getfattr -d /mnt/file > getfattr: Removing leading '/' from absolute path names > # file: mnt/file > user.foo0="bar0" What size is the inode ? This problem happens if the size is larger than 128 byte. (I tested at 256 byte inode.) Thanks, Masayoshi -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c index 5e0faf4..69c3d47 100644 --- a/fs/ext3/inode.c +++ b/fs/ext3/inode.c @@ -2914,13 +2914,7 @@ struct inode *ext3_iget(struct super_block *sb, unsigned long ino) atomic_set(&ei->i_datasync_tid, tid); } - if (inode->i_ino >= EXT3_FIRST_INO(inode->i_sb) + 1 && - EXT3_INODE_SIZE(inode->i_sb) > EXT3_GOOD_OLD_INODE_SIZE) { - /* - * When mke2fs creates big inodes it does not zero out - * the unused bytes above EXT3_GOOD_OLD_INODE_SIZE, - * so ignore those first few inodes. - */ + if (EXT3_INODE_SIZE(inode->i_sb) > EXT3_GOOD_OLD_INODE_SIZE) { ei->i_extra_isize = le16_to_cpu(raw_inode->i_extra_isize); if (EXT3_GOOD_OLD_INODE_SIZE + ei->i_extra_isize > EXT3_INODE_SIZE(inode->i_sb)) {
In ext3 filesystem, if following conditions 1., 2., 3. and 4. is satisfied, getfattr can't search the extended attribute (EA) after remount. Condition: 1. the inode size is over 128 byte 2. "lost+found" whose inode number is 11 was removed 3. the 11th inode is used for a file. 4. the EA locates in-inode This happens because of following logic: i_extra_isize is set to over 0 by ext3_new_inode() when we create a file whose inode number is 11 after removing "lost+found". Therefore setfattr creates the EA in-inode. After remount, i_extra_isize of 11th inode is set to 0 by ext3_iget() when we lookup the file, so getfattr tries to search the EA out-inode. However, the EA locates in-inode, so getfattr can't search the EA. How to reproduce: 1. mkfs.ext3 -I 256 /dev/sdXX 2. mount -o acl,user_xattr /dev/sdXX /TEST 3. rm -rf /TEST/* 4. touch /TEST/file (whose inode number is 11) 5. cd /TEST; setfattr -n user.foo0 -v bar0 file 6. cd /TEST; getfattr -d file -> can see foo0/bar0 7. umount /dev/sdXX 8. mount -o acl,user_xattr /dev/sdXX /TEST 9. cd /TEST; getfattr -d file -> can't see foo0/bar0 Though the 11th inode is used for "lost+found" normally, the other file can also use it. Therefore, i_extra_isize of 11th inode should be set to the suitable value by ext3_iget(). CC: Andreas Dilger <adilger.kernel@dilger.ca> Signed-off-by: Masayoshi MIZUMA <m.mizuma@jp.fujitsu.com> --- fs/ext3/inode.c | 8 +------- 1 files changed, 1 insertions(+), 7 deletions(-)