linux-kernel - Re: [PATCH 0/3] kobject tracepoints

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: <20160906193018.GB21213@kroah.com>
Date:   Tue, 6 Sep 2016 21:30:18 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Shuah Khan <shuahkh@....samsung.com>
Cc:     rostedt@...dmis.org, mingo@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] kobject tracepoints

On Tue, Sep 06, 2016 at 11:49:22AM -0600, Shuah Khan wrote:
> Add kobject trace points to track kobject operations: init, add, set_name,
> init_and_add, create_and_add, move, rename, get, put, cleanup, and del.
> 
> Kobject trace points can aid in debugging, generating status and graphs
> on kobjects in the kernel and their hierarchy.

What type of "graphs"?  Isn't this just too noisy to ever find anything
"real"?

> This patch series adds kobject tracepoints and adds calls to tracepoints
> from kobject init, add, set_name, init_and_add, create_and_add, move,
> rename, get, put, cleanup, and del operations.
> 
> A suggestion to provide more visibility into kboject lifetimes came out of
> a discussion at my Embedded data structure lifetime talk at LinuxCon NA in
> Toronto. As I thought about on how to provide visibility, I decided adding
> traces provides a boot and run-time facility to trace kobject operations
> without needing compile special kernels and also without impacting run-time
> unless trace is enabled. Hence, this resulting patch series.
> 
> Example traces:
> 
> <...>-13632 [003] d... 11296.965114: kobject_get: KOBJECT: 1:0:0:0 (f
> fff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 19
>            <...>-13632 [003] d... 11296.965167: kobject_get: KOBJECT: 1:0:0:0 (ffff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 20
>            <...>-13632 [003] d... 11296.965218: kobject_get: KOBJECT: 1:0:0:0 (ffff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 21
>            <...>-13632 [003] d... 11296.965269: kobject_get: KOBJECT: 1:0:0:0 (ffff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 22
>           <idle>-0     [006] ..s. 11296.965378: kobject_put: KOBJECT: 1:0:0:0 (ffff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 21
>           <idle>-0     [006] .Ns. 11296.965542: kobject_put: KOBJECT: 1:0:0:0 (ffff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 20
>      ksoftirqd/6-46    [006] ..s. 11296.965633: kobject_put: KOBJECT: 1:0:0:0 (ffff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 19
>      ksoftirqd/6-46    [006] ..s. 11296.965703: kobject_put: KOBJECT: 1:0:0:0 (ffff88034aeb1348) state=1 parent= target1:0:0 (ffff88038c875db8) counter= 18
> 
> Shuah Khan (3):
>   kobject: add kobject trace points
>   kobject: add kobject trace prototypes
>   kobject: Add calls to kobject trace points
> 
>  include/trace/events/kobject.h | 259 +++++++++++++++++++++++++++++++++++++++++
>  lib/Makefile                   |   2 +-
>  lib/kobject.c                  |  22 ++++
>  lib/kobject_traces.c           |  32 +++++
>  4 files changed, 314 insertions(+), 1 deletion(-)
>  create mode 100644 include/trace/events/kobject.h
>  create mode 100644 lib/kobject_traces.c

I've strongly resisted tracepoints in the driver core, and kobjects,
because of the implicit "userspace API" guarantees that some people see
these as.  I notice that Al Viro just posted a proposal to the ksummit
mailing list to potentially talk about this very issue.

I'm really curious as to exactly what these tracepoints can buy us,
other than drowning in them as devices are added and removed from the
system?  Isn't this just too noisy for any real use?

And again, I worry about people relying on them, as we have changed the
internals of kobjects at times over the years, I don't want to have to
worry about somehow keeping these tracepoints "identical" for the next
40+ years.

thanks,

greg k-h