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>] [day] [month] [year] [list]
Message-ID: <20070612123219.GE32163@frankl.hpl.hp.com>
Date:	Tue, 12 Jun 2007 05:32:19 -0700
From:	Stephane Eranian <eranian@....hp.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Stephane Eranian <eranian@....hp.com>, levon@...ementarian.org
Subject: problem with NMI MSR reserve routines

Andi,

I am running into several issues related to the newly restructured
NMI MSR allocator in perfctr-watchdog.c. There are issues with Oprofile
and also with perfmon.

Let me describe the Oprofile issue first (because perfmon is similar).
The fill_in_addresses() callback for Oprofile systematically invokes the
reserve_perfctr_nmi()/reserve_evntsel_nmi() routines regardless
of whether NMI watchdog is active or not. It uses those routines as
a generic PMU register allocator which it is not in its current form.

The issue is that the reserve_*() have a side effect when wd_ops is not
yet defined. The nmi_*_msr_to_bit() routines return 0 which means you've
collapsed all MSR to a single bit. The first reserve() will return success
the others will return failure, thus the caller will assume only one PMU
register is present. This what you can see in the following trace for
Oprofile on Opteron with nmi_watchdog=0:

tired kernel: res_ctr @0xc0010004 returns 1 (success)
tired kernel: res_ctr @0xc0010005 returns 0 (failure)
tired kernel: res_ctr @0xc0010006 returns 0
tired kernel: res_ctr @0xc0010007 returns 0

tired kernel: res_sel @0xc0010000 returns 1 (success)
tired kernel: res_sel @0xc0010001 returns 0 (failure)
tired kernel: res_sel @0xc0010002 returns 0
tired kernel: res_sel @0xc0010003 returns 0

I think we either need to fix up fill_in_addresses X86 routines to check
for nmi_watchdog() or (better) change the allocator to work differently,be
independent of NMI watchdog.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ