I agree that RUSAGE_THREAD is fine. (In fact, if you'd pressed me to
remember without looking, I would have assumed we put it in already.)
However, in the implementation, I would keep it cleaner by moving the
identical code from inside the loop under case RUSAGE_SELF into a shared
subfunction, rather than duplicating it. In fact, here you go (next posting).
As to getting arbitrary other threads' data, there are several problems
there. Adding a syscall is often more trouble than it's worth. Ulrich
cited the issues with that as the API. You also didn't handle compat for
it correctly. To warrant the code necessary to make this available by
whatever API, I think you need to say some more about what it's needed for.
Off hand, it seems most in keeping with other things to expose this via a
/proc file, i.e. /proc/tgid/task/tid/rusage and (/proc/tgid/rusage for the
RUSAGE_SELF behavior on a foreign process). There we already have the
infrastructure for dealing with the security issues uniformly with how we
control other similar information. Personally I tend to prefer a binary
interface, i.e. a virtual file whose contents are struct rusage; for that
you still need to do the extra compat work, since a 32-bit process should
have the 32-bit struct rusage layout in its /proc files. If you put the
numbers into ascii text as some /proc interfaces do, you don't need any
special considerations for CONFIG_COMPAT.
Thanks,
Roland
--
