linux-kernel - Re: [PATCH] perf: Fix probing for PERF_FLAG_FD

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: <54E61D49.9000605@intel.com>
Date:	Thu, 19 Feb 2015 19:28:41 +0200
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	David Ahern <david.ahern@...cle.com>,
	David Ahern <dsahern@...il.com>, acme@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf: Fix probing for PERF_FLAG_FD_CLOEXEC flag

On 19/02/2015 6:22 p.m., David Ahern wrote:
> On 2/19/15 9:17 AM, Adrian Hunter wrote:
>> Yes, I am sorry it is a pain. I don't know why I didn't add a comment
>> to the code :-(. Using -1 for the pid is a workaround to avoid gratuitous
>> jump label changes. If pid=0 is used and then a system-wide trace is done
>> with Intel PT, there will be a jump label change shortly after the tracing
>> starts. That means the running code gets changed, but Intel PT decoding
>> has to walk the code to reconstruct the trace - so errors result. There
>> will always be occasional jump label changes, but this avoids one that
>> would otherwise always happen.
>
> I don't understand the response. Why can't pid == getpid() (ie., pid > 0)

IIRC pid == getpid() is the same as pid = 0

 > be used for this test? pid = -1 and pid = 0 are not needed. With pid > 0
 > cpu value does not matter so cpu = -1 can be used. Again this is just to
 > determine if the kernel supports PERF_FLAG_FD_CLOEXEC. Existence of PT
 > should not be involved here.

This is about the side-effects of opening perf events. One of the side-effects
is that some jump labels get switched. For optimization reasons, there is then
a delay before they switch back. That means that a side-effect of probing the
API is that jump label changes, that otherwise would not have happened, appear
during the trace.

This is not only about Intel PT. From an abstract point of view, it is
about minimizing the disturbance to the system under test.


--
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/