Tetsuo Handa wrote: > Then, next suspicious part would be ccs_flush(). I'm reading it now.
I found the cause of infinite loop while reading /proc/ccs/audit and /proc/ccs/query interfaces. In ccs_flush(), head->r.w[0] holds pointer to string data to be printed. But head->r.w[0] was updated only when the string data was partially printed (because head->r.w[0] will be updated by head->r.w[1] later). However, regarding /proc/ccs/audit and /proc/ccs/query , an additional '\0' is printed after the string data was completely printed. But if free space for read buffer became 0 before printing the additional '\0', ccs_flush() was returning without updating head->r.w[0]. As a result, ccs_flush() reprints already printed string data. For example, when ccs_flush() was about to print "foo\0" and read buffer size was 1 for each read() call, ccs_flush() prints 'f' + 'o' + 'o' + 'o' + 'o' + 'o' + ... rather than 'f' + 'o' + 'o' + '\0'. For example, if the buffer size for read() equals to length of the string data to be printed, ccs_flush() will continue printing the same string data forever (without '\0'). This was what I observed and fixed in revision 4536. Now, the question is that the program you saw using the top command was ccs-editpolicy rather than ccs-auditd or ccs-queryd , wasn't it? ccs-editpolicy does not read /proc/ccs/audit nor /proc/ccs/query . Maybe infinite loop has occurred somewhere else. If you experienced the loop again, please do ls -l /proc/`pidof ccs-editpolicy`/fd/ strace -p `pidof ccs-editpolicy` and check what file the ccs-editpolicy was reading and what string data are read. I think we can guess the location from directives in the string data. Regards. _______________________________________________ tomoyo-dev-en mailing list tomoyo-dev-en@lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
