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: <m13amg9fl0.fsf@frodo.ebiederm.org>
Date:	Fri, 11 Jul 2008 16:16:43 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.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>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH -v2] ftrace: Documentation

Andrew Morton <akpm@...ux-foundation.org> writes:

> On Fri, 11 Jul 2008 16:59:53 -0400 (EDT) Steven Rostedt <rostedt@...dmis.org>

>> > > +
>> > > +Here's an example of the output format of the file "trace"
>> > > +
>> > > +                             --------
>> > > +# tracer: ftrace
>> > > +#
>> > > +#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
>> > > +#              | |      |          |         |
>> > > +            bash-4251  [01] 10152.583854: path_put <-path_walk
>> > > +            bash-4251  [01] 10152.583855: dput <-path_put
>> > > +            bash-4251  [01] 10152.583855: _atomic_dec_and_lock <-dput
>> > > +                             --------
>> >
>> > pids are no longer unique system-wide, and any part of the kernel ABI which
>> > exports them to userspace is, basically, broken.  Oh well.
>> 
>> What should be used instead?  Of course we're not using a kernel ABI, we
>> are using an API (text based ;-) But more on that later.
>
> 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?

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.

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/