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]
Date:   Sun, 5 Dec 2021 15:15:58 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Stephane Eranian <eranian@...gle.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Ian Rogers <irogers@...gle.com>,
        Namhyung Kim <namhyung@...gle.com>,
        Song Liu <songliubraving@...com>
Subject: Re: [PATCH v2] perf/core: Set event shadow time for inactive events
 too

On Tue, Nov 30, 2021 at 08:58:07PM -0800, Namhyung Kim wrote:
> From: Namhyung Kim <namhyung@...gle.com>
> 
> While f79256532682 ("perf/core: fix userpage->time_enabled of inactive
> events") fixed this problem for user rdpmc usage, bperf (perf stat
> with BPF) still has the same problem that accessing inactive perf
> events from BPF using bpf_perf_event_read_value().
> 
> +static inline void group_update_event_time(struct perf_event *group_event)
>  {
> +	struct perf_event *event;
> +	struct perf_event_context *ctx = group_event->ctx;

:-( surely you're aware of the reverse xmas tree thing by now?

>  
> +	perf_event_update_time(group_event);
> +	perf_set_shadow_time(group_event, ctx);
>  
> +	for_each_sibling_event(event, group_event) {
> +		perf_event_update_time(event);
> +		perf_set_shadow_time(event, ctx);
> +	}
>  
> +	if (likely(!atomic_read(&group_event->mmap_count)))
>  		return;
>  
> +	perf_event_update_userpage(group_event);
> +
>  	for_each_sibling_event(event, group_event)
> +		perf_event_update_userpage(event);

How does it make sense to chase those pointers twice?

>  }

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ