linux-kernel - Re: Oprofile Regression Caused by commit e5d1367f17ba6a6fed5fd8b74e4d5720923e0c25 on PPC

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:	Mon, 10 Oct 2011 19:38:42 -0400
From:	Eric B Munson <emunson@...bm.net>
To:	eranian@...gle.com
Cc:	a.p.zijlstra@...llo.nl, mingo@...e.hu, anton@...ba.org,
	linux-kernel@...r.kernel.org, paulus@...ba.org, hbabu@...ibm.com
Subject: Re: Oprofile Regression Caused by commit
 e5d1367f17ba6a6fed5fd8b74e4d5720923e0c25 on PPC

On Fri, 07 Oct 2011, Eric B Munson wrote:

> This commit seems to have caused a regression with oprofile.  It is fairly easy
> to trigger, simply run oprofile monitoring an event that will fire (something
> frequent like CPU cycles) causes oprofile to fail saying that the PMU is in use.
> If I disable CONFIG_CGROUP_PERF, everything goes back to working.  I suspect the
> problem is that the PMU is being initialized without being reserved for perf.  I
> am not yet sure of the right fix yet so if you have any suggestions I would
> appreciate them.
> 
> Eric

This isn't the best description of the behavior we see, what happens is at some
point in the profiling session the MMCR register is clobbered by
perf_cgroup_switch() which calls perf_pmu_enable() without reserving the PMC
hardware.  When this happens oprofile stops counting.  It doesn't happen each
time so some runs show event counts that are reasonable, but it can also lead to
event counts that are smaller than expected, or completely missing.

Eric

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)