On 09/11/2013 09:25 PM, Theodore Ts'o wrote:
> On Wed, Sep 11, 2013 at 03:48:57PM -0500, Eric Sandeen wrote:
>>
>> So at this point I think it's up to Mak to figure out why on his system,
>> aim7 is triggering mbcache codepaths.
>>
>
> Yes, the next thing is to see if on his systems, whether or not he's
> seeing external xattr blocks.
>
> - Ted
>
I seem to be seeing the same thing as Eric is seeing.
On one of my systems,
# find / -mount -exec getfattr --only-values -m security.* {} 2>/dev/null \; |
wc -c
2725655
# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/vg_dhg1-lv_root
[tmac@lxbuild linux]$ man find
1974272 84737 1889535 5% /
# find /home -mount -exec getfattr --only-values -m security.* {} 2>/dev/null
\; | wc -c
274173
# df -i /home
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/vg_dhg1-lv_home
192384 7862 184522 5% /home
For both filesystems, the security xattr are about 32.17 and 34.87 bytes
respectively.
I also see a similar problem with filefrag.
# filefrag -xv /bin/sh
Filesystem type is: ef53
File size of /bin/sh is 938736 (230 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 23622459548 100 not_aligned,inline
/bin/sh: 1 extent found
# getfattr -m - -d /bin/sh
getfattr: Removing leading '/' from absolute path names
# file: bin/sh
security.selinux="system_u:object_r:shell_exec_t:s0"
debugfs: stat /bin/sh
Inode: 1441795 Type: symlink Mode: 0777 Flags: 0x0
Generation: 3470616846 Version: 0x00000000:00000001
User: 0 Group: 0 Size: 4
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x50c2779d:ad792a58 -- Fri Dec 7 16:11:25 2012
atime: 0x52311211:006d1658 -- Wed Sep 11 19:00:01 2013
mtime: 0x50c2779d:ad792a58 -- Fri Dec 7 16:11:25 2012
crtime: 0x50c2779d:ad792a58 -- Fri Dec 7 16:11:25 2012
Size of extra inode fields: 28
Extended attributes stored in inode body:
selinux = "system_u:object_r:bin_t:s0\000" (27)
Fast_link_dest: bash
At this point, I'm not sure why we get into the mbcache path when SELinux is
enabled. As mentioned in one my earlier replies to Andreas, I did see actual
calls into ext4_xattr_cache.
There seems to be one difference between 3.11 kernel and 2.6 kernel in
set_inode_init_security(). There is an additional attempt to initialize evm
xattr. But I do not seem to be seeing any evm xattr in any file.
I will continue to try to find out how we get into the mbcache path. Please
let me know if anyone has any suggestion.
Thanks,
Mak.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
