[tomoyo-dev-en 130] Re: Memory problem

アーカイブの一覧に戻る

Tetsuo Handa from-****@I-lov*****
Sat Feb 5 23:44:09 JST 2011


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.




More information about the tomoyo-dev-en mailing list
アーカイブの一覧に戻る