linux-kernel - Re: [PATCH] [21/58] i386: Reserve the right performance counter for the Intel PerfMon NMI watchdog

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, 19 Jul 2007 12:45:26 +0200
From:	Andi Kleen <ak@...e.de>
To:	BjÃ¶rn Steinbrink <B.Steinbrink@....de>
Cc:	patches@...-64.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [21/58] i386: Reserve the right performance counter for the Intel PerfMon NMI watchdog

On Thursday 19 July 2007 12:21:45 BjÃ¶rn Steinbrink wrote:
> On 2007.07.19 11:55:06 +0200, Andi Kleen wrote:
> > 
> > From: [** iso-8859-1 charset **] BjörnSteinbrink <B.Steinbrink@....de>
> > 
> > The Intel PerfMon NMI watchdog was using the generic reservation
> > function which always reserves the first performance counter. But the
> > watchdog actually uses the second performance counter, thus we need a
> > specialised function.
> 
> Ah, almost forgot about that patch. Actually, thanks to your fix that
> basically reverted the msr->offset conversation to its 2.6.21
> implementation, single_msr_reserve has sane semantics now and does just
> what the name suggests (before, the wd_ops entries had to store the
> "base" msrs, so it was really a first_msr_reserve).
> 
> With wd_ops->perfctr no longer needed to be the base msr, we can just
> fix that value for the arch perfmon watchdog. (And maybe we should
> remove the values for those implementations that don't employ the
> single_msr_reserve() stuff?)

I replaced the patch with the new patch, thanks

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