linux-kernel - Re: [RFC] btf: Some structs are doubled because of struct ring

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: <20191213165155.vimm27wo7brkh3yu@ast-mbp.dhcp.thefacebook.com>
Date:   Fri, 13 Dec 2019 08:51:57 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Jiri Olsa <jolsa@...hat.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        Quentin Monnet <quentin.monnet@...ronome.com>
Subject: Re: [RFC] btf: Some structs are doubled because of struct ring_buffer

On Fri, Dec 13, 2019 at 11:25:00AM -0500, Steven Rostedt wrote:
> On Fri, 13 Dec 2019 16:35:53 +0100
> Jiri Olsa <jolsa@...hat.com> wrote:
> 
> > I don't think dedup algorithm can handle this and I'm not sure if there's
> > some way in pahole to detect/prevent this.
> > 
> > I only found that if I rename the ring_buffer objects to have distinct
> > names, it will help:
> > 
> >   $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep task_struct
> >   [150] STRUCT 'task_struct' size=11008 vlen=205
> > 
> >   $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "STRUCT 'perf_event'"
> >   [1665] STRUCT 'perf_event' size=1160 vlen=70
> > 
> > also the BTF data get smaller ;-) before:
> > 
> >   $ ll /sys/kernel/btf/vmlinux
> >   -r--r--r--. 1 root root 2067432 Dec 13 22:56 /sys/kernel/btf/vmlinux
> > 
> > after:
> >   $ ll /sys/kernel/btf/vmlinux
> >   -r--r--r--. 1 root root 1984345 Dec 13 23:02 /sys/kernel/btf/vmlinux
> > 
> > 
> > Peter, Steven,
> > if above is correct and there's no other better solution, would it be possible
> > to straighten up the namespace and user some distinct names for perf and ftrace
> > ring buffers?
> 
> Now, the ring buffer that ftrace uses is not specific for ftrace or
> even tracing for that matter. It is a stand alone ring buffer (oprofile
> uses it), and can be used by anyone else.
> 
> As the perf ring buffer is very coupled with perf (or perf events), and
> unless something changed, I was never able to pull the perf ring
> buffer out as a stand alone ring buffer.
> 
> As the ring buffer in the tracing directory is more generic, and not to
> mention around longer, if one is to change the name, I would suggest it
> be the perf ring buffer.

Thanks Jiri to bring it up.
Technically the kernel is written in valid C, but it's imo the case where C
standard isn't doing that great.

To rephrase what Jiri said...
If include/linux/perf_event.h instead of saying 'struct ring_buffer;'
would have done #include <kernel/events/internal.h>
the kernel/trace/ring_buffer.c would have had build error.
Even now sizeof(*perf_event->rb) would return different values depending
whether it's used in kernel/trace/ring_buffer.c or anywhere in kernel/events/.
dwarf/btf and gcc cannot deal with it nicely. It's a valid C.

'gdb vmlinux' for sizeof(struct ring_buffer) will pick perf ring buffer.
It had two choices. Both valid. I don't know why gdb picked this one.
So yeah I think renaming 'ring_buffer' either in ftrace or in perf would be
good. I think renaming ftrace one would be better, since gdb picked perf one
for whatever reason.