Re: [TOMOYO 1/2] tomoyo: add Documentation/tomoyo.txt

From: Tetsuo Handa
Date: Mon May 04 2009 - 02:24:25 EST


Pavel Machek wrote:
> The document above says otherwise. 'There is no way except rebooting
> the system that can free unneeded memory' certainly looks like memory
> leak. Plus it sounds like if you change the policy, it will not free
> the old one, either.

Comments on documentation are also appreciated.
Let me explain it with below examle.

# echo 'allow_read /lib/libc-2.5.so' | ccs-loadpolicy -e
# echo 'delete allow_read /lib/libc-2.5.so' | ccs-loadpolicy -e
# echo 'allow_read /lib/libc-2.5.so' | ccs-loadpolicy -e
# echo 'allow_read /lib/libc-2.6.so' | ccs-loadpolicy -e

In the first line, new memory is allocated because that element has never been
added to the list before.
In the second line, memory used for the deleted element is not released.
In the third line, new memory is not allocated because that element has been
added in the past.
In the fourth line, new memory is allocated because that element has never been
added to the list before.

Memory which becomes garbage (which some people call as "memory leak") is
quite little because a sane administrator won't add random elements and delete
them.

TOMOYO has cursors used for resuming list traversal from arbitrary elements.
I tried to add refcounter to each element, but the code became too ugly to
maintain. Thus, I simplified list traversal by guaranteeing all elements
pointed by cursors are permanent. As of now, we can't release memory used by
the deleted element because we don't manage the list of cursors to make sure
that there is no cursor which refers the deleted element. But if we can find
a way to detect no longer referenced elements, we would be able to add some
garbage collector. (Before we start implementing garbage collector, I'd like to
hear end-user's opinion whether TOMOYO wants garbage collector or not.)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/