linux-kernel - Re: [PATCH v12] perf: Sharing PMU counters across compatible events

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: <20200421071850.GO20730@hirez.programming.kicks-ass.net>
Date:   Tue, 21 Apr 2020 09:18:50 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Song Liu <songliubraving@...com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>, Tejun Heo <tj@...nel.org>,
        kernel test robot <rong.a.chen@...el.com>
Subject: Re: [PATCH v12] perf: Sharing PMU counters across compatible events

On Tue, Apr 21, 2020 at 01:13:32AM +0000, Song Liu wrote:
> >> static inline u64 perf_event_count(struct perf_event *event)
> >> {
> >> -	return local64_read(&event->count) + atomic64_read(&event->child_count);
> >> +	u64 count;
> >> +
> >> +	if (likely(event->dup_master != event))
> >> +		count = local64_read(&event->count);
> >> +	else
> >> +		count = local64_read(&event->master_count);
> >> +
> >> +	return count + atomic64_read(&event->child_count);
> >> }
> > 
> > So lsat time I said something about SMP ordering here. Where did that
> > go?
> 
> I guess we will need something with EVENT_TOMBSTONE? That's not clean, I guess.
> 
> > 
> > Specifically, without ordering it is possible to observe dup_master and
> > dup_count out of order. So while we might then see dup_master, we might
> > then also see an old dup_count, which would give 'interesting' effects.
> > 
> > Granted, adding memory barriers all over this will suck :/
> 
> Can we somehow guarantee dup_master and the counts sits in the same 
> cache line? In that way, we can get rid of most of these barriers. 

I'm afraid memory ordering doesn't quite work that way. It is also very
much outside every architectural guarantee ever written.

In specific this does not consider store buffers and snoops.