[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKTCnzmM1sNqf4udk+osgYgY6zk8tQYx7DN0K02MBHuRCOYShQ@mail.gmail.com>
Date: Mon, 3 Oct 2011 20:22:45 +0530
From: Balbir Singh <bsingharora@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Guillaume Chazarain <guichaz@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: taskstats root only breaking iotop
On Sun, Oct 2, 2011 at 3:29 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sat, Oct 1, 2011 at 2:54 PM, Guillaume Chazarain <guichaz@...il.com> wrote:
> >
> > With taskstats being root only, what's the benefit of making the stats
> > imprecise (not that it matters to iotop)?
>
> I think the question should be: why is it *ever* a good idea to let
> *anybody* read how many bytes anybody has read.
>
> If you want that kind of detail, do "strace". Don't do that abortion
> that is taskstats.
>
> > - byte level stats only if ptrace_may_access() though iotop can
> > certainly live with 1k rounded values
>
> Again, do a real trace.
>
> Right now, TASKSTATS is a total and utter disaster. I want to make it
> *less* used, not more. And I sure as hell don't want to make it even
> *more* of a burden on the kernel by having to do the whole ptrace
> check on each and every task.
>
> Seriously. TASKSTATS is crap. It should die. I was *this* close to
> deciding to just rip it out entirely. The whole thing is badly
> designed, it's known-broken wrt namespaces, and it's a crazy idea to
> begin with.
>
Namespaces came in later, much later after taskstats. I think your
biased and not even thinking about your bias. What was badly designed?
It was reviewed several times in the community and tested for
performance. I've tried convincing you before, but I need a constant
supply of energy drinks to keep this fight going. How about we be
practical about the issue at hand, IOW
1. What would a better design look like
2. What can we do to fix the broken namespace
3. The theoretical security issues might exist (I say might), but no
one has demonstrated an attack with it. I agree on the ssh key size
issue being exposed via io portion of taskstats, but beyond that I;d a
dummies guide to help me understand.
Balbir Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists