linux-kernel - Re: [PATCH 3/3] ftrace: trace single pid for function graph tracer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0812032330500.5240@gandalf.stny.rr.com>
Date:	Wed, 3 Dec 2008 23:32:20 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, fweisbec@...il.com,
	peterz@...radead.org, arjan@...radead.org, dave@...ux.vnet.ibm.com,
	containers@...ts.osdl.org, sukadev@...ux.vnet.ibm.com,
	serue@...ibm.com, srostedt@...hat.com
Subject: Re: [PATCH 3/3] ftrace: trace single pid for function graph tracer


On Wed, 3 Dec 2008, Eric W. Biederman wrote:

> Steven Rostedt <rostedt@...dmis.org> writes:
> 
> > On Wed, 3 Dec 2008, Eric W. Biederman wrote:
> >
> >> Steven Rostedt <rostedt@...dmis.org> writes:
> >> 
> >> The way patch 2 uses pids is just stupid.  It has nothing to do with
> >> pids aren't unique.  You do a full walk of the process list instead
> >> of using the hash table.
> >
> > The way patch 2 uses the pids is stupid, it was just the easiest way to 
> > implement it correctly ;-)  I work with, do it stupid but correct first, 
> > then optimize.
> 
> Which is a reasonable and very unix approach.  As long as I don't need to
> do more than advise about what to do.

No prob. I already wrote the patch and I'm just about ready to post.

> 
> >> It makes me think that task->pid really should go away because with it
> >> there people don't bother to look and see how things normally work.
> >
> > This is far from a fast path, and I can easily fix it. The hard work was 
> > the rest of the patch not this part. I even did it stupid knowing that I 
> > would be rewriting it to handle namespaces. I stated that this needed to 
> > be fixed in the patch itself.
> >
> > One thing I never got an answer for, using the namespace pid path, can I 
> > still select the idle task to trace, i.e. pid == 0.
> 
> Sorry I didn't see this question.  As I recall we have a special pid that
> is not hashed that is used by the idle task.  
> 
> So it should be possible but it would need to be a special case.  Although
> please note we have one idle task per cpu.

Yep, I'm almost finish with this patch. It is a special case.

> 
> Is the idle task doing anything interesting enough to warrant tracing?
> We don't report the idle tasks in proc or in any of our other user space
> interfaces.

Yes, because we can see what wakes things up from idle. That is, if we 
trace the idle task, we can trace the interrupts that happen while the CPU 
is idle.

Thanks,

-- Steve

--
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/