linux-kernel - Re: [PATCH V2 2/6] perf/x86/intel/pebs: Fix PEBS timestamps overwritten

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

Message-ID: <CAM9d7cgWDVAq8-11RbJ2uGfwkKD6fA-OMwOKDrNUrU_=8MgEjg@mail.gmail.com>
Date:   Tue, 11 Oct 2022 11:20:54 -0700
From:   Namhyung Kim <namhyung@...nel.org>
To:     Kan Liang <kan.liang@...ux.intel.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Stephane Eranian <eranian@...gle.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>, andreas.kogler.0x@...il.com,
        Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
        Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [PATCH V2 2/6] perf/x86/intel/pebs: Fix PEBS timestamps overwritten

Hello,

On Thu, Sep 1, 2022 at 6:10 AM <kan.liang@...ux.intel.com> wrote:
>
> From: Kan Liang <kan.liang@...ux.intel.com>
>
> The PEBS TSC-based timestamps do not appear correctly in the final
> perf.data output file from perf record.
>
> The data->time field setup by PEBS in the setup_pebs_fixed_sample_data()
> is later overwritten by perf_events generic code in
> perf_prepare_sample(). There is an ordering problem.
>
> Set the sample flags when the data->time is updated by PEBS.
> The data->time field will not be overwritten anymore.

I have a report that it breaks the symbolization of samples.
It seems time is not in sync between perf_clock and PEBS.

One thing I noticed is that the system has a config option
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y.
Looking at the code, it seems sched_clock is doing some
adjustments in that case.  So I'm not sure if it'd work well
on those systems.

Thoughts?

Thanks,
Namhyung


>
> Reported-by: Andreas Kogler <andreas.kogler.0x@...il.com>
> Reported-by: Stephane Eranian <eranian@...gle.com>
> Signed-off-by: Kan Liang <kan.liang@...ux.intel.com>
> ---
>  arch/x86/events/intel/ds.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index de1f55d51784..01cbe26225c2 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -1643,8 +1643,10 @@ static void setup_pebs_fixed_sample_data(struct perf_event *event,
>          * We can only do this for the default trace clock.
>          */
>         if (x86_pmu.intel_cap.pebs_format >= 3 &&
> -               event->attr.use_clockid == 0)
> +               event->attr.use_clockid == 0) {
>                 data->time = native_sched_clock_from_tsc(pebs->tsc);
> +               data->sample_flags |= PERF_SAMPLE_TIME;
> +       }
>
>         if (has_branch_stack(event))
>                 data->br_stack = &cpuc->lbr_stack;
> @@ -1705,8 +1707,10 @@ static void setup_pebs_adaptive_sample_data(struct perf_event *event,
>         perf_sample_data_init(data, 0, event->hw.last_period);
>         data->period = event->hw.last_period;
>
> -       if (event->attr.use_clockid == 0)
> +       if (event->attr.use_clockid == 0) {
>                 data->time = native_sched_clock_from_tsc(basic->tsc);
> +               data->sample_flags |= PERF_SAMPLE_TIME;
> +       }
>
>         /*
>          * We must however always use iregs for the unwinder to stay sane; the
> --
> 2.35.1
>