Re: [RFC] Per-thread getrusage

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Vinay Sridhar <vinay@...>
Cc: <linux-kernel@...>, <libc-alpha@...>, <wli@...>, <akpm@...>, <sripathik@...>
Date: Thursday, January 17, 2008 - 11:42 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vinay Sridhar wrote:

You're doing two things at once:

a) provide a way to get a thread's usage

b) provide a way to get another process's/thread's usage


The former is a trivial extension and I completely agree.  RUSAGE_THREAD
is trivial to implement and should go in ASAP.

The second part isn't that easy.  The first question is: do we really
need this?  It is a new type of interface.  We have the /proc filesystem
etc for programs which want to look at other process' data.  Second,
more importantly right now, your patch seems not to include any security
support.  Correct me if I'm wrong, but find_task_by_pid will always
succeed, regardless of whether the calling thread belongs to another UID
or not.  I.e., your patch enables any process to read any other process'
usage.  That's a no-no.


I suggest that you split the patch in two.  The first should implement
RUSAGE_THREAD.  You'll immediately get an ACK from me for that.  The
second part then should introduce a way to get another process' usage.
This patch should only be used initially as a starting point for
discussions.  You'll have to argue why it is necessary in the first place.

The argument might have to do with why you want a pthread_getrusage()
interface (which, btw, is a bad name since the interface is nothing like
getrusage, getrusage doesn't allow requesting any other process' data).
 Yes, for intra-process lookups relying on /proc is no good idea.  But
then, I have not seen any reason so far why such an API is needed and
why a thread cannot just be responsible for reading its own usage data.
 Anyway, if pthread_getrusage (or whatever it'll be called) is the only
usage then the syscall should require that the TID parameter is from a
thread in the same process which would solve the security problem.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHj3do2ijCOnn/RHQRAiKdAKCSooiEWcxr780hJGenElyDiWPWKgCdE+6Y
j6ibmGsPT4aYxhSfpimSdiw=
=jOC9
-----END PGP SIGNATURE-----
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC] Per-thread getrusage, Vinay Sridhar, (Thu Jan 17, 4:27 am)
Re: [RFC] Per-thread getrusage, Andrew Morton, (Mon Jan 28, 1:52 am)
Re: [RFC] Per-thread getrusage, Sripathi Kodi, (Mon Jan 28, 4:24 am)
Re: [RFC] Per-thread getrusage, Andrew Morton, (Mon Jan 28, 5:22 am)
Re: [RFC] Per-thread getrusage, Pavel Emelyanov, (Mon Jan 28, 3:48 am)
Re: [RFC] Per-thread getrusage, Andrew Morton, (Mon Jan 28, 5:10 am)
Re: [RFC] Per-thread getrusage, Pavel Emelyanov, (Mon Jan 28, 5:38 am)
Re: [RFC] Per-thread getrusage, Andrew Morton, (Mon Jan 28, 5:45 am)
Re: [RFC] Per-thread getrusage, Pavel Emelyanov, (Mon Jan 28, 5:57 am)
Re: [RFC] Per-thread getrusage, Eric W. Biederman, (Mon Jan 28, 4:43 pm)
Re: [RFC] Per-thread getrusage, Pavel Emelyanov, (Tue Jan 29, 4:29 am)
Re: [RFC] Per-thread getrusage, Andrew Morton, (Mon Jan 28, 5:57 pm)
Re: [RFC] Per-thread getrusage, Pavel Emelyanov, (Tue Jan 29, 4:17 am)
Re: [RFC] Per-thread getrusage, Roland McGrath, (Fri Jan 18, 9:14 pm)
[PATCH] RUSAGE_THREAD, Roland McGrath, (Fri Jan 18, 9:14 pm)
Re: [PATCH] RUSAGE_THREAD, Michael Kerrisk, (Sat Jan 26, 3:23 am)
Re: [PATCH] RUSAGE_THREAD, Christoph Hellwig, (Mon Jan 21, 5:55 am)
Re: [PATCH] RUSAGE_THREAD, Ulrich Drepper, (Sat Jan 19, 2:21 am)
Re: [RFC] Per-thread getrusage, Ulrich Drepper, (Thu Jan 17, 11:42 am)