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-next>] [day] [month] [year] [list]
Message-ID: <f26be5e-af31-a996-9c7-86d9d1ed4b2@maine.edu>
Date:   Fri, 17 Jun 2022 16:13:22 -0400 (EDT)
From:   Vince Weaver <vincent.weaver@...ne.edu>
To:     linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org
cc:     Mark Rutland <mark.rutland@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Will Deacon <will@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>
Subject: READ_ONCE() usage in perf_mmap_read_self()

Hello
 
Is the perf_mmap__read_self() interface as found in tools/lib/perf/mmap.c
the "official" interface for accessing the perf mmap info from
userspace?
 
Are the READ_ONCE() calls required?  If they are left out, will accessing 
the mmap interface potentially fail?  Has this ever been seen in practice?
 
Part of why I am asking is both
 	tools/lib/perf/mmap.c
and
 	tools/linux/compiler.h (which defines READ_ONCE)
have SPDX headers indicating they are GPL-2.0 licensed, which means it 
seems like it would not be possible to easily use the perf mmap interface 
from BSD-licensed code.  Would it be possible to get those two files 
re-licensed?
 
The (BSD-licensed) PAPI is currently using a mmap reading interface 
based on early documentation for the feature, but it isn't 100% the same 
as the version from libperf (and isn't using READ_ONCE).  Life would be 
easier if we could use the perf version of the code because then we would 
have one less variable to deal with when trying to track down issues.
 
Vince Weaver
vincent.weaver@...ne.edu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ