| 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
| ||
|
Date: Thu, 8 Feb 2018 13:22:50 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Tom Zanussi <tom.zanussi@...ux.intel.com>,
linux-rt-users@...r.kernel.org, linux-trace-users@...r.kernel.org,
Clark Williams <williams@...hat.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>
Subject: Re: [PATCH 11/20 v2] tracing: Add symbol type to function based
events
Em Thu, Feb 08, 2018 at 10:59:00AM -0500, Steven Rostedt escreveu:
> On Thu, 8 Feb 2018 12:20:31 +0100
> Jiri Olsa <jolsa@...hat.com> wrote:
>
> > > +Symbols (function names)
> > > +========================
> > > +
> > > +To display kallsyms "%pS" type of output, use the special type "symbol".
> > > +
> > > +Again, using gdb to find the offset of the "func" field of struct work_struct
> > > +
> > > +(gdb) printf "%d\n", &((struct work_struct *)0)->func
> > > +24
> >
> > you could also use Arnaldo's pahole for this, seems like less typing:
> >
> > $ pahole ./vmlinux -C work_struct
> > die__process_function: tag not supported (INVALID)!
> > struct work_struct {
> > atomic_long_t data; /* 0 8 */
> > struct list_head entry; /* 8 16 */
> > work_func_t func; /* 24 8 */
> >
> > it's in 'dwarves' package
>
> Nice, I'll have to document that:
>
> $ pahole ./vmlinux -C net_device |grep perm
> unsigned char perm_addr[32]; /* 558 32 */
You can also use just one .o file to speed things up instead of using
vmlinux, where it ill go on parsing stuff till it finds a .o with that
struct definition, i.e.:
[acme@...et linux]$ pahole -C work_struct ../build/v4.15.0-rc9+/kernel/sys.o
struct work_struct {
atomic_long_t data; /* 0 8 */
struct list_head entry; /* 8 16 */
work_func_t func; /* 24 8 */
/* size: 32, cachelines: 1, members: 3 */
/* last cacheline: 32 bytes */
};
One may prefer hexadecimal numbers:
[acme@...et linux]$ pahole --hex -C work_struct ../build/v4.15.0-rc9+/kernel/sys.o
struct work_struct {
atomic_long_t data; /* 0 0x8 */
struct list_head entry; /* 0x8 0x10 */
work_func_t func; /* 0x18 0x8 */
/* size: 32, cachelines: 1, members: 3 */
/* last cacheline: 32 bytes */
};
[acme@...et linux]$
Or even expand everything and get offsets from that work_struct to
inside the list_head or other embedded types:
[acme@...et linux]$ pahole -E --hex -C work_struct ../build/v4.15.0-rc9+/kernel/sys.o
struct work_struct {
/* typedef atomic_long_t -> atomic64_t */ struct {
long int counter; /* 0 0x8 */
} data; /* 0 0x8 */
struct list_head {
struct list_head * next; /* 0x8 0x8 */
struct list_head * prev; /* 0x10 0x8 */
} entry; /* 0x8 0x10 */
/* typedef work_func_t */ void (*func)(struct work_struct *); /* 0x18 0x8 */
/* size: 32, cachelines: 1, members: 3 */
/* last cacheline: 32 bytes */
};
[acme@...et linux]$
A long time ago I put the expansion of task_struct somewhere... yeah,
almost a decade ago, 2008, but it was not -E, was -p (i.e. expand
pointer types):
http://vger.kernel.org/~acme/vmlinux-expand_pointers-task_struct.txt
/* size: 1680, cachelines: 27, members: 141 */
/* sum members: 1641, holes: 10, sum holes: 39 */
/* bit holes: 1, sum bit holes: 31 bits */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 16 bytes */
};
Anyway, now we have:
[acme@...et linux]$ pahole -C task_struct ../build/v4.15.0-rc9+/kernel/sys.o | tail -6
struct thread_struct thread; /* 6592 4352 */
/* size: 10944, cachelines: 171, members: 4 */
/* sum members: 10896, holes: 1, sum holes: 48 */
/* paddings: 1, sum paddings: 48 */
};
[acme@...et linux]$
We have way more memory and features now :-)
The number of members is because now we have that randomize_struct stuff
that creates an unamed struct inside task_struct, so we have:
struct task_struct {
struct thread_info thread_info; /* 0 8 */
volatile long int state; /* 8 8 */
/* XXX 48 bytes hole, try to pack */
/* --- cacheline 1 boundary (64 bytes) --- */
struct {
void * stack; /* 64 8 */
atomic_t usage; /* 72 4 */
<SNIP>
int pagefault_disabled; /* 6504 4 */
/* XXX 4 bytes hole, try to pack */
struct task_struct * oom_reaper_list; /* 6512 8 */
struct vm_struct * stack_vm_area; /* 6520 8 */
/* --- cacheline 102 boundary (6528 bytes) --- */
atomic_t stack_refcount; /* 6528 4 */
/* XXX 4 bytes hole, try to pack */
void * security; /* 6536 8 */
}; /* 64 6528 */
/* XXX last struct has 48 bytes of padding */
/* --- cacheline 103 boundary (6592 bytes) --- */
struct thread_struct thread; /* 6592 4352 */
/* size: 10944, cachelines: 171, members: 4 */
/* sum members: 10896, holes: 1, sum holes: 48 */
/* paddings: 1, sum paddings: 48 */
};
So indeed, 'just' 4 members.
I guess I'll have to add some new mode where one can ask for unnamed
structs to be removed for the sake of --reorganize and the summary
information at the end, erm...
Anyway, digressed too much :-)
- Arnaldo
Powered by blists - more mailing lists