linux-kernel - [RFC] adding of TGID to ftrace output

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-next>] [day] [month] [year] [list]

Message-ID: <CAJWu+ooo0YSxm5w64txV=s0fOVXW_UXWKs783eQpGTBjaDUQNA@mail.gmail.com>
Date:   Wed, 10 May 2017 16:04:55 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: [RFC] adding of TGID to ftrace output

Hi Steven,

Can we add TGID information along with PID to ftrace output?

Something like:
#                                   _-----=> irqs-off
#                                  / _----=> need-resched
#                                 | / _---=> hardirq/softirq
#                                 || / _--=> preempt-depth
#                                 ||| /     delay
#           TASK-PID:TGID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |     |      |   ||||       |         |
            bash-1977:1977  [000] .... 17284.993652: sys_close <-

Instead of:
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
            bash-1977  [000] .... 17284.993652: sys_close <-

Currently in android, we inject tgid into each trace event at the end
of the trace just so we can group threads under a process in our trace
viewer.

The other option we're thinking off is we can retrieve tgid during the
trace output (reading trace file from debugfs/tracefs) from the
task_struct and then have ftrace output it that way.

Anyway, having this will really simplify things and make it more
reliable (we run ps -T at the end of the trace right now, but its
unreliable because threads might have exited by then). We also have to
call getpid() and inject pid into each userspace trace_marker write
just so we can do this grouping.

Regards,
Joel