linux-kernel - hpet_disable() call sites

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-next>] [day] [month] [year] [list]

Message-Id: <4F719449020000780007B0CD@nat28.tlf.novell.com>
Date:	Tue, 27 Mar 2012 09:19:53 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	<mingo@...e.hu>, <hirofumi@...l.parknet.co.jp>
Cc:	<tglx@...utronix.de>, <linux-kernel@...r.kernel.org>,
	<hpa@...or.com>
Subject: hpet_disable() call sites

In c86c7fbc829e27e2a4093f98ded9fbd75e515adb (and subsequently
0c1b2724069951b1902373e688042b2ec382f68f) hpet_disable() gets
called in the shutdown path. The first of them gives HPET enabling
through PCI quirks in conjunction with the use of legacy replacement
as sole reason, yet even outside of the context of either the starting
up kernel has a problem if the HPET is in an unexpected state, in
particular preventing "normal" timer interrupts from occurring (which
was in particular found to be the case during kdump attempts after
Xen was running).

Is there any reason why hpet_disable() should not also be called
from (or some equivalent action be taken, perhaps including clearing
certain bits in the individual counters' configuration registers, which
are apparently - but perhaps wrongly - implied to be clear in e.g.
hpet_set_mode(), in) hpet_enable()?

Thanks, Jan

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