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: <m1hc5kvabf.fsf@frodo.ebiederm.org>
Date:	Wed, 03 Dec 2008 20:22:28 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Steven Rostedt <rostedt@...dmis.org>
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

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.

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

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.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ