linux-kernel - Re: [PATCH] hangcheck-timer is broken on x86

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]

Message-ID: <1269881007.1857.18.camel@work-vm>
Date:	Mon, 29 Mar 2010 09:43:27 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Yury Polyanskiy <ypolyans@...nceton.edu>
Cc:	Joel Becker <Joel.Becker@...cle.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...l.org>,
	Jan Glauber <jan.glauber@...ibm.com>
Subject: Re: [PATCH] hangcheck-timer is broken on x86

On Mon, 2010-03-29 at 10:11 -0400, Yury Polyanskiy wrote:
> On Sun, 28 Mar 2010 18:00:36 -0700
> john stultz <johnstul@...ibm.com> wrote:
> 
> > > 1) Does getrawmonotonic() satisfy hangcheck-timer?  What I mean is, will
> > > it always return the wallclock nanoseconds even in the face of CPU speed
> > > changes, suspend, udelay, or any other suspension of kernel operation?
> > > Yes, I know this is a tougher standard than rdtsc(), but this is what
> > > hangcheck-timer wants.  rdtsc() at least satisfied udelay and PCI hangs.
> > 
> > getrawmonotonic() can be stalled and will wrap on some hardware (acpi pm
> > timer wraps every 5 seconds).
> > 
> 
> I am not sure which archs do you mean. But in any case,
> getrawmonotonic() is not just a wrap around a call to rdtsc() (or acpi
> pm timer read). It is based on the clock->raw_time, which is updated
> every timer interrupt by the update_wall_time(). So even if underlying
> timer wraps, it doesn't lead to getrawmonotonic() returning 0 sec.

What I'm saying is that if you're using getrawmonotonic() to detect
hangs, you might miss them, as getrawmonotonic may wrap (and thus stop
continually increasing) if the timer interrupt is delayed. This does not
apply to systems using the TSC clocksource, but does apply to systems
using the acpi_pm. 

read_persistent_clock() is likely a better interface to use, because it
returns the seconds usually from the CMOS clock which runs continually
without any OS maintenance. 

The only complication there would likely be hwclock syncing (either by
hand or via NTP), but that could be handled by a
touch_hangcheck_watchdog() style notifier. 

thanks
-john


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