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]

Date:	Mon, 14 Jul 2008 21:08:32 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
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


On Fri, 11 Jul 2008, Eric W. Biederman wrote:

> Andrew Morton <akpm@...ux-foundation.org> writes:
> >
> > Well that's an interesting question and it has come up before.  There
> > are times when the kernel wants to display a process identifier at
> > least in a printk.  Oopses are one prominent example.
> >
> > Perhaps we do need a way of doing this in a post-pid-namespace-world.
> > Presumably it would be of the form "pidns-identifier:pid", and just
> > plain old "pid" if no pid namespaces are in operation, for some
> > back-compatibility where possible.
> >
> > Eric, any thoughts?
>
> I don't quite know what we are doing here.  Is this a /proc or /sysfs file?

Actually it is a /debug (or /sys/mount/debug if you prefer) file.

>
> After a long series of discussion on semantics what we came up with
> was that the pid namespaces are hierarchical and that a struct pid
> will have a numerical identifier in each pid namespace.  Which means
> that for printing pids in the case of printks especially for oops
> reports we can just go with pid number in the init_pid_ns.  Which is
> the classic system wide pid.
>
> In every other case I know besides printk we are delivering the data to an
> application, and that application is running in a pid namespace
> therefore we really want to figure out the pid namespace and give it the
> information.
>
> For filesystem interfaces (besides proc which provides a natural split)
> the classic answer is to capture namespaces at mount time.  And display
> the data in the filesystem relative to the namespaces we captured.

I'd be interested in knowing who would want namespaces in traces. I've
basically only used tracing to see "what's happening in the kernel here?".
Where I only use the pid to differentiate between the tasks I know are
running.

Hence, tracing is much like printk. Does it really matter with these
outputs. But ftrace is pluggable, pid namespaces may matter in future
plugins.

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