From: Roland McGrath <roland@redhat.com>
To: Vinay Sridhar <vinay@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, libc-alpha@sourceware.org,
drepper@redhat.com, wli@holomorphy.com,
akpm@linux-foundation.org, sripathik@in.ibm.com
Subject: Re: [RFC] Per-thread getrusage
Date: Fri, 18 Jan 2008 17:14:13 -0800 (PST) [thread overview]
Message-ID: <20080119011413.4B2CD26F9FD@magilla.localdomain> (raw)
In-Reply-To: Vinay Sridhar's message of Thursday, 17 January 2008 13:57:05 +0530 <1200558425.5992.17.camel@srivinay.in.ibm.com>
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
next prev parent reply other threads:[~2008-01-19 1:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 8:27 Vinay Sridhar
2008-01-17 15:42 ` Ulrich Drepper
2008-01-19 1:14 ` Roland McGrath [this message]
2008-01-19 1:14 ` [PATCH] RUSAGE_THREAD Roland McGrath
2008-01-19 6:21 ` Ulrich Drepper
2008-01-21 9:55 ` Christoph Hellwig
2008-01-26 7:23 ` Michael Kerrisk
2008-01-28 5:52 ` [RFC] Per-thread getrusage Andrew Morton
2008-01-28 7:48 ` Pavel Emelyanov
2008-01-28 9:10 ` Andrew Morton
2008-01-28 9:38 ` Pavel Emelyanov
2008-01-28 9:45 ` Andrew Morton
2008-01-28 9:57 ` Pavel Emelyanov
2008-01-28 20:43 ` Eric W. Biederman
2008-01-28 21:57 ` Andrew Morton
2008-01-29 8:17 ` Pavel Emelyanov
2008-01-29 8:29 ` Pavel Emelyanov
2008-01-28 8:24 ` Sripathi Kodi
2008-01-28 9:22 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080119011413.4B2CD26F9FD@magilla.localdomain \
--to=roland@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=drepper@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sripathik@in.ibm.com \
--cc=vinay@linux.vnet.ibm.com \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®