linux-kernel - Re: 2.6.18 perfmon new code base + libpfm + pfmon

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:	Thu, 28 Sep 2006 10:05:08 +0200
From:	Andi Kleen <ak@...e.de>
To:	eranian@....hp.com
Cc:	perfmon@...ali.hpl.hp.com, linux-ia64@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...l.org
Subject: Re: 2.6.18 perfmon new code base + libpfm + pfmon

On Thursday 28 September 2006 09:56, Stephane Eranian wrote:
> Andi,
> 
> 
> > > [ak] : may have to add __kprobes to some functions
> > > 	- started doing this on some functions. Need better understanding on when to use this
> > 
> > Basically when you could recurse in kprobes. 
> > 
> My understanding is that kprobes are triggered by breakpoints, so I am think that any 
> perfmon function that can be called along the same path, i.e., traps, needs to have the
> __kprobes prefix.

Only when you call perfmon from the int3 path or any code that is shared.

But it is actually more complicated because page faults can be used by
kprobes too.

> > > [ak] : cleaner integration with NMI watchdog
> > > 	- integration done on AMD K8. Issues on P4, P6, due to PMU design
> > 
> > What are the issues?
> 
> This is ugly!
> 
> The P6 PMU actually has only one enable bit for all counters and it is in PERFEVTSEL0 which
> you are using for NMI. Thus counters are NOT independent. Architectural perfmon looks like
> it is fixing this issue.  I am not sure this is actually true based on the findings of the
> PAPI people for instance.
> 
> The P4 PMU has independent counters, i.e., enable bits. The issue is that to stop a counter
> requires clearing the CCCR which also contains the overflow information (has the counter
> overflowed?). So you need to read the CCCR, save the value somewhere, clear the CCCR.
> You need some save area that you can safely access without grabbing any lock (because you
> are in the NMI handler).

Not sure what the lock would be needed for. It is only a per CPU variable that doesn't
need synchronization no? 

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