linux-kernel - Re: [PATCH] ftrace: add simple oneshot function 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190709135346.r4m4izzhgk55kniy@stud.informatik.uni-erlangen.de>
Date:   Tue, 9 Jul 2019 15:53:46 +0200
From:   Thomas Preisner <linux@...eisner.de>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Thomas Preisner <linux@...eisner.de>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ftrace: add simple oneshot function tracer

On Wed, Jun 26, 2019 at 12:04:12PM -0400, Steven Rostedt wrote:
> On Sun, 23 Jun 2019 14:05:55 +0200
> Thomas Preisner <linux@...eisner.de> wrote:
> > I've created this tracer with kernel tailoring in mind since the
> > tailoring process of e.g. undertaker heavily benefits from a more
> > precise set of input data.
> > 
> > A "oneshot" option for the function tracer would be a viable
> > possibility. However, this may add a lot of overhead (performance wise)
> > in comparison to my current approach? After all, the use case of my
> > tracer would be some sort of kernel activity monitoring during "normal
> > usage" in order to get a grasp of (hopefully) all required kernel
> > functions.
> 
> Coming back from vacation and not having this threaded in my inbox,
> I have to ask (to help cache this back into my head), what was the
> "current approach" compared to the "oneshot" option, and why would it
> have better performance?

The current approach makes use of ftrace's profiling capabilities in
conjunction with a hashtable and preallocated memory for its entries.
When active, this oneshot-profiler will only perform lookups for ip and
parent_ip and insert those when necessary. Compared to the "oneshot"
option this allows to omit values that are not required for kernel
profiling such as interrupt flags, etc. However, I am not sure how huge
this may impact the performance.

Nonetheless, the profiling variant allows to remove duplicated entries
(due to there being one hashset per CPU core) before outputting its
gathered data. Additionally, it is independent of the ringbuffer which
may overflow due to other tracers being active (However, I am not sure
if or in which way different tracers are isolated from each other when
using the ringbuffer, so this may as well be false).

> > 
> > Also, there is no strong reason to add a new event type,
> > this was just a means of reducing the collected data (which may as well
> > be omitted since there is no real benefit).
> 
> +1
> 
> > 
> > My "oneshot tracer" actually collects and outputs every parent in order
> > to get a more thorough view on used kernel code. Therefore, I would
> > suggest to keep this functionality and maybe make it configurable
> > instead?
> 
> Configure which? (again, coming back from vacation, I need a refresher
> on this ;-)

In case you want to incorporate this oneshot functionality directly into
the function tracer as a new option it may be useful to allow
configuring the tracer's oneshot capabilities. This way, one could
disable tracing of a function after its first occurrence or instead keep
tracing enabled in order to get a better overview over where it was
called from (-> recording the parent_ip is also interesting).

Yours sincerely,
Thomas