linux-kernel - Re: Problem running perf using Intel-PT with snapshots

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <CBE205D4-C798-419D-A9B2-42870245B885@gmail.com>
Date:   Thu, 18 May 2023 10:56:02 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-perf-users@...r.kernel.org
Subject: Re: Problem running perf using Intel-PT with snapshots



> On May 18, 2023, at 12:52 AM, Adrian Hunter <adrian.hunter@...el.com> wrote:
> 
> On 18/05/23 07:26, Nadav Amit wrote:
>> Hello perf masters,
>> 
>> I am running perf with Intel PT with snapshot mode and the result makes no
>> sense. I tried to figure it out myself but failed.
>> 
>> Excluding the first data file, the rest seem messed up in various ways. The
>> only thing that repeatedly shows are calls to __fentry__+0x0. I would note
>> that ftrace is not enabled, and I turned off mitigations as I thought it
>> might somehow be related, but it did not help.
>> 
>> Here is an example for execution and output. In between I ran
>> `kill -SIGUSR2 [perf-pid]`. To dump some traces.
>> 
>> Any ideas what it might be?
>> 
>> Thanks,
>> Nadav
>> 
>> --
>> 
>> $ perf record -e intel_pt/noretcomp=1/k --kcore --timestamp -a --snapshot=e262144 --switch-output -m,64
> 
> --switch-output does not work well with Intel PT.  Intel PT needs all of the sideband event information from all files, so decoding errors result from splitting files.
> 
> If you need separate files, consider stopping and restarting 'perf record' instead.  If you do that, you may want to look at options like -B and -N and --no-bpf-event which can affect how long it takes to stop perf record.
> 
> If you don't need separate files, you can use --time to look at time ranges within the resulting perf.data file.

Thank you Adrian. It was driving me crazy and I was sure I am somehow not
accounting for some ftrace/rethunk or some other binary rewriting event.

These ideas for workarounds should suffice.

Thanks again,
Nadav