| 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
| ||
|
Message-ID: <873ae6wgd6.fsf@basil.nowhere.org> Date: Sun, 22 Feb 2009 18:06:45 +0100 From: Andi Kleen <andi@...stfloor.org> To: David Miller <davem@...emloft.net> cc: linux-kernel@...r.kernel.org Subject: Re: x86's nmi_hz wrt. oprofile's nmi_timer_int.c David Miller <davem@...emloft.net> writes: Really old mail, but I was very behind. I didn't see an correct answer, so let's answer it. > While working on an NMI watchdog implementation on sparc64 > I noticed what seems to be a peculiar behavior of the NMI > timer int oprofile support on x86. > > When the NMI watchdog tests itself at boot timer we start > with nmi_hz equal to HZ. > > After the NMI watchdog self-test passes, nmi_hz is reduced > down to '1'. > > The NMI timer int oprofile support simply uses DIE_NMI notifiers for > it's implementation. But I don't see anything in the code of > arch/x86/oprofile/nmi_timer_int.c nor the NMI watchdog infrastructure > which will re-adjust nmi_hz back to HZ or something similar. > > Am I missing something? oprofile generates its own NMIs, it does not rely on the ones from the nmi watchdog. In timer mode it does not use nmis or die notifiers, but relies on the regular non nmi timer interrupt. Does that answer your question? -Andi -- ak@...ux.intel.com -- Speaking for myself only. -- 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/
Powered by blists - more mailing lists