From: William Lee Irwin III <wli@holomorphy.com>
To: Roger Luethi <rl@hellgate.ch>
Cc: Albert Cahalan <albert@users.sf.net>,
Stephen Smalley <sds@epoch.ncsc.mil>,
Andrew Morton OSDL <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
Albert Cahalan <albert@users.sourceforge.net>,
Paul Jackson <pj@sgi.com>, James Morris <jmorris@redhat.com>,
Chris Wright <chrisw@osdl.org>
Subject: Re: [1/1][PATCH] nproc v2: netlink access to /proc information
Date: Tue, 14 Sep 2004 01:01:32 -0700 [thread overview]
Message-ID: <20040914080132.GJ9106@holomorphy.com> (raw)
In-Reply-To: <20040914075508.GA10880@k3.hellgate.ch>
On Tue, 14 Sep 2004 00:10:58 -0700, William Lee Irwin III wrote:
>> The concern appears to be that the tools might interpret failed
>> permission checks as indications of process nonexistence. I don't
>> regard this as particularly pressing, as properly-written apps should
>> check the specific value of errno (in particular to retry when EAGAIN
>> is received in numerous contexts).
On Tue, Sep 14, 2004 at 09:55:08AM +0200, Roger Luethi wrote:
> I would expect a tool to refrain from asking for fields with restricted
> access if it needs a complete overview over existing processes. It can
> always ask for restricted fields in a second request (the vast majority
> of fields are world-readable anyway).
That expectation can't be entirely relied upon, as the restrictions may
not be predictable.
On Tue, 14 Sep 2004 00:10:58 -0700, William Lee Irwin III wrote:
>> Distinguishing between EPERM, ENOSYS, ENOENT, etc. could probably be
>> done if the fields are measured in units such that the top bit is never
>> set for any feasible value, then a fully qualified error return could
>> simply be returned as (unsigned long)(-err). I suspect VSZ may be
>> problematic wrt. overflows even for 32-bit, not just for 31-bit.
On Tue, Sep 14, 2004 at 09:55:08AM +0200, Roger Luethi wrote:
> Yeah, that makes me nervous. There are just too many ways this can go
> wrong or be misinterpreted in user space. Currently, nproc does not
> indicate the type of error at all, because a properly written user-space
> app will either not hit an error or be able to figure out what the
> problem was based on the available information. I suppose if we wanted
> to change that (which doesn't sound unreasonable), the proper way would
> be to return error flags with an error message (delivered via netlink).
This kind of error reporting is better still, as the fields then won't
be polluted with invalid data under any circumstance (assuming the code
can report subsets of the fields or some such, which I presume to be
the case given that avoiding reporting potentially computationally
expensive fields was one of the original motivators of the patch).
-- wli
next prev parent reply other threads:[~2004-09-14 8:12 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 18:40 [0/1][ANNOUNCE] nproc v2: netlink access to /proc information Roger Luethi
2004-09-08 18:41 ` [1/1][PATCH] " Roger Luethi
2004-09-09 0:35 ` William Lee Irwin III
2004-09-09 0:43 ` William Lee Irwin III
2004-09-09 1:15 ` William Lee Irwin III
2004-09-09 1:17 ` [1/2] rediff nproc v2 vs. 2.6.9-rc1-mm4 William Lee Irwin III
2004-09-09 1:21 ` [2/2] handle CONFIG_MMU=n and use new vm stats for CONFIG_MMU=y William Lee Irwin III
2004-09-09 1:22 ` William Lee Irwin III
2004-09-09 1:26 ` [3/2] round up text memory to the nearest page in fs/proc/task_mmu.c William Lee Irwin III
2004-09-09 18:43 ` [1/1][PATCH] nproc v2: netlink access to /proc information Roger Luethi
2004-09-09 18:49 ` William Lee Irwin III
2004-09-09 19:00 ` William Lee Irwin III
2004-09-09 19:02 ` [4/2] consolidate __task_mem() and __task_mem_cheap() William Lee Irwin III
2004-09-09 19:07 ` Roger Luethi
2004-09-09 19:15 ` [5/2] fix nommu VSZ reporting in consolidated task_mem() William Lee Irwin III
2004-09-09 19:11 ` [1/1][PATCH] nproc v2: netlink access to /proc information Roger Luethi
2004-09-09 19:23 ` William Lee Irwin III
2004-09-09 21:19 ` Roger Luethi
2004-09-10 15:30 ` Roger Luethi
2004-09-11 22:25 ` Albert Cahalan
2004-09-12 4:58 ` William Lee Irwin III
2004-09-14 5:59 ` Roger Luethi
2004-09-14 6:18 ` William Lee Irwin III
2004-09-14 6:23 ` William Lee Irwin III
2004-09-14 7:47 ` Greg Ungerer
2004-09-14 8:27 ` Roger Luethi
2004-09-09 11:53 ` Stephen Smalley
2004-09-09 17:22 ` William Lee Irwin III
2004-09-09 17:53 ` Roger Luethi
2004-09-09 20:01 ` Stephen Smalley
2004-09-09 20:48 ` Chris Wright
2004-09-10 12:11 ` Stephen Smalley
2004-09-09 20:55 ` Roger Luethi
2004-09-09 21:05 ` Chris Wright
2004-09-09 21:25 ` Roger Luethi
2004-09-11 22:36 ` Albert Cahalan
2004-09-12 5:00 ` William Lee Irwin III
2004-09-14 6:44 ` Roger Luethi
2004-09-14 7:10 ` William Lee Irwin III
2004-09-14 7:55 ` Roger Luethi
2004-09-14 8:01 ` William Lee Irwin III [this message]
2004-09-14 9:27 ` Roger Luethi
2004-09-14 15:37 ` William Lee Irwin III
2004-09-14 16:01 ` Roger Luethi
2004-09-14 16:37 ` William Lee Irwin III
2004-09-14 17:15 ` Roger Luethi
2004-09-14 17:43 ` William Lee Irwin III
2004-09-14 18:45 ` Roger Luethi
2004-09-14 19:07 ` William Lee Irwin III
2004-09-14 19:31 ` Roger Luethi
2004-09-14 19:36 ` William Lee Irwin III
2004-09-14 19:50 ` Roger Luethi
2004-09-15 11:44 ` Roger Luethi
2004-09-15 20:02 ` Roger Luethi
2004-09-15 20:20 ` William Lee Irwin III
2004-09-15 20:33 ` Roger Luethi
2004-09-15 20:44 ` Roger Luethi
2004-09-14 18:37 ` Chris Wright
2004-09-14 18:55 ` Roger Luethi
2004-09-14 19:05 ` Chris Wright
2004-09-14 21:12 ` Roger Luethi
2004-09-09 20:44 ` Chris Wright
2004-09-16 21:43 ` nproc: So? Roger Luethi
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=20040914080132.GJ9106@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=albert@users.sf.net \
--cc=albert@users.sourceforge.net \
--cc=chrisw@osdl.org \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=rl@hellgate.ch \
--cc=sds@epoch.ncsc.mil \
/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