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:	Wed, 6 Nov 2013 08:50:47 -0500 (EST)
From:	Vince Weaver <vince@...ter.net>
To:	mingo@...nel.org, hpa@...or.com, anton@...ba.org,
	mathieu.desnoyers@...ymtl.ca, linux-kernel@...r.kernel.org,
	peterz@...radead.org, michael@...erman.id.au,
	paulmck@...ux.vnet.ibm.com, benh@...nel.crashing.org,
	fweisbec@...il.com, VICTORK@...ibm.com, tglx@...utronix.de,
	oleg@...hat.com, mikey@...ling.org
cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/core] tools/perf: Add required memory barriers

On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:

> Commit-ID:  a94d342b9cb09edfe888ea972af0883b6a8d992b
> Gitweb:     http://git.kernel.org/tip/a94d342b9cb09edfe888ea972af0883b6a8d992b
> Author:     Peter Zijlstra <peterz@...radead.org>
> AuthorDate: Wed, 30 Oct 2013 11:42:46 +0100
> Committer:  Ingo Molnar <mingo@...nel.org>
> CommitDate: Wed, 6 Nov 2013 12:34:26 +0100
> 
> tools/perf: Add required memory barriers
> 
> To match patch bf378d341e48 ("perf: Fix perf ring buffer memory
> ordering") change userspace to also adhere to the ordering outlined.

...

> +++ b/tools/perf/util/evlist.h
> @@ -177,7 +177,7 @@ int perf_evlist__strerror_open(struct perf_evlist *evlist, int err, char *buf, s
>  static inline unsigned int perf_mmap__read_head(struct perf_mmap *mm)
>  {
>  	struct perf_event_mmap_page *pc = mm->base;
> -	int head = pc->data_head;
> +	int head = ACCESS_ONCE(pc->data_head);
>  	rmb();
>  	return head;

so is this ACCESS_ONCE required now for proper access to the mmap buffer?

remember that there are users trying to use this outside of the kernel 
where we don't necessarily have access to internal kernl macros.  Some of 
these users aren't necessarily GPLv2 compatible either (PAPI for example 
is more or less BSD licensed) so just cutting and pasting chunks of 
internal kernel macros isn't always the best route either.

Vince

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ