linux-kernel - Re: [PATCH -v2] ftrace: Documentation

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: <m1fxqbj2c4.fsf@frodo.ebiederm.org>
Date:	Mon, 14 Jul 2008 19:41:47 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Elias Oltmanns <eo@...ensachen.de>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Clark Williams <clark.williams@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jon Masters <jonathan@...masters.org>
Subject: Re: [PATCH -v2] ftrace: Documentation

Steven Rostedt <rostedt@...dmis.org> writes:

>> Ok.  So this is something simpler to use then SystemTap.  Yeah.
>
> Yes, very similar.  SystemTap may even hook into ftrace, and vice versa.

Got it.

>> It sounds like it is reasonable or at least semi reasonable to use
>> this as an unprivileged user.
>
> Currently only root can do the traces. Since some of the tracing can
> hurt the performance of the system.

Reasonable.

>> The easiest model to think of this in is a chroot that does pids as
>> well as the filesystem.  In which case if you are inside one and
>> you use the tracer.  You want pids that are meaningful in your
>> subset of userspace, and not the global ones.
>
> Some tracers do a trace at every function call. This uses the gcc -pg
> option to set up the start of each function to call profiling code.
> Dynamic ftrace is a on the fly code modification to maintain good
> performance while tracing is disabled.
>
> Because of this being such a high critical path, can I get the namespace
> pid information directly from the task structure. Any function that is
> called must also be careful to not fall back into the tracer. The trace
> deals with self recursion, but functions that call back to the tracer
> cause a bigger performance impact while tracing.

All of the interesting functions are inline so it shouldn't be a big deal.
Mostly they exist to keep the semantics clear as we refactor the code.
task_pid_nr(tsk) yields the global pid number, and is currently implemented as just tsk->pid.
task_pid(tsk) yields the struct pid.

task_pid_nr_ns(tsk) yields the pid number from the perspective of a specific
task.

struct pid is interesting because it is immune from pid roll over conflicts.
I don't know if that is any use to you or not.

stuct pid contains an embedded array of the pid_nrs one for each namespace the
struct pid is in.

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/