linux-kernel - Re: [tip:perf/core] perf: Rework the PMU methods

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:	Tue, 14 Sep 2010 22:11:10 +1200
From:	Michael Cree <mcree@...on.net.nz>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	mingo@...hat.com, dengcheng.zhu@...il.com,
	yanmin_zhang@...ux.intel.com, gorcunov@...il.com,
	fweisbec@...il.com, robert.richter@....com, ming.m.lin@...el.com,
	tglx@...utronix.de, hpa@...or.com, paulus@...ba.org,
	linux-kernel@...r.kernel.org, eranian@...glemail.com,
	will.deacon@....com, lethal@...ux-sh.org, davem@...emloft.net,
	mingo@...e.hu, linux-alpha@...r.kernel.org
Subject: Re: [tip:perf/core] perf: Rework the PMU methods

On 14/09/10 01:18, Peter Zijlstra wrote:
> On Mon, 2010-09-13 at 14:15 +0200, Peter Zijlstra wrote:
>> On Sun, 2010-09-12 at 17:33 +1200, Michael Cree wrote:
>>
>>> I've also tested it on a UP alpha.  It worked well for a little while
>>> but after running 'perf top' for a number of seconds I got the following
>>> warning:

>> Ahh, the alpha throttle call should be using the fancy new stop function
>> too (will fold into your earlier patch if it indeed works):
>>
>> As to the point you raised above, yes, I think it would be prudent to
>> call perf_event_do_pending() before update_process_times().
>>
>>
>> Signed-off-by: Peter Zijlstra<a.p.zijlstra@...llo.nl>
>
> Damn I suck.. Please try this one.
>
> ---
> Index: linux-2.6/arch/alpha/kernel/perf_event.c
> ===================================================================
> --- linux-2.6.orig/arch/alpha/kernel/perf_event.c
> +++ linux-2.6/arch/alpha/kernel/perf_event.c
> @@ -850,7 +850,7 @@ static void alpha_perf_event_irq_handler
>   			/* Interrupts coming too quickly; "throttle" the
>   			 * counter, i.e., disable it for a little while.
>   			 */
> -			cpuc->idx_mask&= ~(1UL<<idx);
> +			alpha_pmu_stop(event, 0);
>   		}
>   	}
>   	wrperfmon(PERFMON_CMD_ENABLE, cpuc->idx_mask);

Thanks, that does the trick.  I have had it running for a while without 
any problems... Well, except for a new problem which I describe below. 
Anyway the above patch has fixed the original problem so can be rolled 
into my earlier one as you suggest.

I haven't shifted perf_event_do_pending() before update_process_times() 
in the timer interrupt yet.  When I get around to it I'll send a patch 
through the Alpha maintainer as this is independent of the work on the 
core perf event code.

Now to the new problem I saw:  I accidently reran 'perf top' while it 
was already running, and the second instance of 'perf top' seg-faulted 
and the kernel OOPSed with the following:

[  818.575752] Unable to handle kernel paging request at virtual address 
0000000000000060
[  818.575752] perf(4935): Oops 0
[  818.575752] pc = [<fffffc000036b8b8>]  ra = [<fffffc000036ba3c>]  ps 
= 0000    Not tainted
[  818.575752] pc is at put_ctx+0x18/0xb0
[  818.575752] ra is at free_event+0xec/0x220
[  818.575752] v0 = 0000000000000000  t0 = 0000000000000000  t1 = 
0000000000000002
[  818.575752] t2 = 0000000000000000  t3 = 0000000000000000  t4 = 
fffffc000063e4b0
[  818.575752] t5 = fffffc0034837000  t6 = fffffc0034837000  t7 = 
fffffc003abe0000
[  818.575752] s0 = 0000000000000000  s1 = 0000000000000000  s2 = 
0000000000000000
[  818.575752] s3 = ffffffffffffffff  s4 = 0000000000000000  s5 = 
0000000000000053
[  818.575752] s6 = fffffc0034836c00
[  818.575752] a0 = 0000000000000000  a1 = fffffc00311a6980  a2 = 
0000000000000000
[  818.575752] a3 = 0000000000000001  a4 = fffffc0000797110  a5 = 
00000001200055f8
[  818.575752] t8 = 0000000000000001  t9 = 00000001200396f4  t10= 
0000000000000000
[  818.575752] t11= 000000000000000a  pv = fffffc000031d650  at = 
fffffc000036f8bc
[  818.575752] gp = fffffc00007d6e40  sp = fffffc003abe3e18
[  818.575752] Disabling lock debugging due to kernel taint
[  818.575752] Trace:
[  818.575752] [<fffffc000036ba3c>] free_event+0xec/0x220
[  818.575752] [<fffffc000036fa24>] SyS_perf_event_open+0x2a4/0x6f0
[  818.575752] [<fffffc0000310c24>] entSys+0xa4/0xc0
[  818.575752]
[  818.575752] Code: 27bb0047  23bdb5a0  23defff0  b53e0008  b75e0000 
47f00409 <a8500060> 40403121

The first instance of 'perf top' kept running happily.

Cheers
Michael.
--
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/