Jamie Nguyen wrote:
> I should also mention that the memory usage jumps up almost instantly.
> It goes from a small amount suddenly to 3GB.
Thank you.
I built vanilla 2.6.37 using your kernel config on CentOS 5.5. I noticed that
the same audit log appear for many times when I did "cat /proc/ccs/*".
Maybe a problem has occurred while reading /proc/ccs/ interface.
#2011/02/05 22:30:33# profile=1 mode=learning granted=no (global-pid=56) task={
pid=56 ppid=55 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0
type!=execute_handler } path1={ uid=0 gid=0 ino=1835522 major=8 minor=1
perm=0755 type=file } path1.parent={ uid=0 gid=0 ino=1835521 perm=0755 } exec={
realpath="/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1" argc=15 envc=12
argv[]={ "/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1" "-quiet" "-iprefix"
"../lib/gcc/x86_64-redhat-linux/4.1.2/" "ccs_bind_test.c" "-quiet" "-dumpbase"
"ccs_bind_test.c" "-mtune=generic" "-auxbase" "ccs_bind_test" "-O2" "-Wall"
"-o" "/tmp/ccGBPUuJ.s" } envp[]={ "_=/usr/bin/make"
"PWD=/root/ccstools/kernel_test" "HOME=/" "SHLVL=1" "OLDPWD=/root/ccstools"
"MAKEFLAGS=" "MFLAGS=" "TERM=linux" "MAKELEVEL=1" "COLLECT_GCC=gcc"
"GCC_EXEC_PREFIX=../lib/gcc/"
"COLLECT_GCC_OPTIONS='-Wall'\040'-O2'\040'-o'\040'ccs_bind_test'\040'-mtune=generic'"
} }
<kernel> /usr/bin/make /usr/bin/gcc
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1
misc env SHLVL
#2011/02/05 22:30:33# profile=1 mode=learning granted=no (global-pid=56) task={
pid=56 ppid=55 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0
type!=execute_handler } path1={ uid=0 gid=0 ino=1835522 major=8 minor=1
perm=0755 type=file } path1.parent={ uid=0 gid=0 ino=1835521 perm=0755 } exec={
realpath="/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1" argc=15 envc=12
argv[]={ "/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1" "-quiet" "-iprefix"
"../lib/gcc/x86_64-redhat-linux/4.1.2/" "ccs_bind_test.c" "-quiet" "-dumpbase"
"ccs_bind_test.c" "-mtune=generic" "-auxbase" "ccs_bind_test" "-O2" "-Wall"
"-o" "/tmp/ccGBPUuJ.s" } envp[]={ "_=/usr/bin/make"
"PWD=/root/ccstools/kernel_test" "HOME=/" "SHLVL=1" "OLDPWD=/root/ccstools"
"MAKEFLAGS=" "MFLAGS=" "TERM=linux" "MAKELEVEL=1" "COLLECT_GCC=gcc"
"GCC_EXEC_PREFIX=../lib/gcc/"
"COLLECT_GCC_OPTIONS='-Wall'\040'-O2'\040'-o'\040'ccs_bind_test'\040'-mtune=generic'"
} }
<kernel> /usr/bin/make /usr/bin/gcc
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1
misc env SHLVL
Audit logs should be removed from the kernel memory when read() via
/proc/ccs/audit interface. ccs_write_log2() adds an audit log and
ccs_read_log() removes that audit log. These operations are protected by
ccs_log_lock spinlock.
spin_lock(&ccs_log_lock);
list_add_tail(&entry->list, &ccs_log);
spin_unlock(&ccs_log_lock);
spin_lock(&ccs_log_lock);
list_del(&ptr->list);
spin_unlock(&ccs_log_lock);
But above output suggests that the audit log was not removed by some reason.
Then, next suspicious part would be ccs_flush(). I'm reading it now.
If the problem you encountered is that ccs-editpolicy continues adding entries
because the kernel has fallen into infinite reading loop while reading
/proc/ccs/domain_policy or /proc/ccs/exception_policy , it is natural that
ccs-editpolicy consumes system's all memory and consumes some of CPU time.
Regards.
_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
