linux-kernel - Re: [GIT PULL] perf fixes

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: <20191101210117.GA52887@gmail.com>
Date:   Fri, 1 Nov 2019 22:01:17 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Arnaldo Carvalho de Melo <acme@...radead.org>,
        Jiri Olsa <jolsa@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] perf fixes


* Ingo Molnar <mingo@...nel.org> wrote:

> This actually works fine in practice. I just tried out a brand new kernel 
> with really old perf tooling in the v3.19 kernel, from 4.5 years ago:
> 
>   $ git checkout v3.19
>   $ cd tools/perf/
>   $ make install WERROR=0
> 
>   $ perf version
>   perf version 3.19.gbfa76d49
> 
>   $ perf top
> 
> This ancient version of 'perf top', 'perf record', 'perf report' works 
> just fine on the new kernel, despite passing in a smaller 'attr':
> 
>   [  558.408907] perf kABI size: 112
>   [  558.412855] perf uABI size: 104
> 
> when running new tooling on a new kernel the two sizes match:
> 
> [  331.598089] perf kABI size: 112
> [  331.602050] perf uABI size: 112
> 
> and everything works as usual.

Out of morbid curiosity I also tried out the v3.2 version of perf 
tooling, which is now more than 7.5 years old, and 'perf record' + 'perf 
report' is working fine on the latest kernel too:


  $ perf version
  perf version 3.2.dirty

  $ perf record ~/hackbench 20
  Time: 0.082
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.828 MB perf.data (~36166 samples) ]

  $ perf report --stdio
  ...
  # Overhead    Command      Shared Object                                      Symbol
  # ........  .........  .................  ..........................................
  #
     6.99%  hackbench  [kernel.kallsyms]  [k] queued_spin_lock_slowpath
     6.22%  hackbench  [kernel.kallsyms]  [k] entry_SYSENTER_compat
     4.06%  hackbench  [kernel.kallsyms]  [k] sysret32_from_system_call
     3.56%  hackbench  [kernel.kallsyms]  [k] do_fast_syscall_32
     3.40%  hackbench  [kernel.kallsyms]  [k] unix_stream_read_generic
     3.32%  hackbench  [kernel.kallsyms]  [k] _raw_spin_lock
     3.13%  hackbench  [kernel.kallsyms]  [k] __slab_free


It works despite 'perf record' using an ancient, 72 bytes long 'struct perf_attr' 
ABI:

  [ 3013.531125] perf kABI size: 112
  [ 3013.535097] perf uABI size: 72

If I'm reading the logs right then the perf ABI went through around ~15 
iterations in the v3.2..v5.4 timeframe that extended struct 
perf_event_attr - but binary compatibility was maintained with ancient 
tooling.

This is also useful for tooling bisectability: tooling should work on new 
and old kernels as well, even if a bisection point moves across ABI 
extension boundaries.

Thanks,

	Ingo