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]

Date:	Sun, 28 Mar 2010 18:00:36 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Joel Becker <Joel.Becker@...cle.com>
Cc:	Yury Polyanskiy <ypolyans@...nceton.edu>,
	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 Fri, 2010-03-26 at 14:46 -0700, Joel Becker wrote:
> On Tue, Mar 23, 2010 at 11:36:11PM -0400, Yury Polyanskiy wrote:
> > Second, and more importantly, loops_per_jiffy has little to do with the conversion from the
> > the time scale of get_cycles() (aka rdtsc) to the time scale of jiffies.
> 
> 	It used to!  Fundamentally, of course, we didn't have a
> monotonic clock everywhere that satisfied hangcheck-timer's needs.  So
> we had to use different approaches on different architectures.
> 
> > @@ -130,7 +129,9 @@ extern unsigned long long monotonic_clock(void);
> >  #else
> >  static inline unsigned long long monotonic_clock(void)
> >  {
> > -	return get_cycles();
> > +	struct timespec ts;
> > +	getrawmonotonic(&ts);
> > +	return timespec_to_ns(&ts);
> >  }
> >  #endif  /* HAVE_MONOTONIC */
> 
> 	I have two questions:
> 
> 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 think the read_persistent_clock() is really what you want to use here.
On arches that do not support it, it returns 0 every time. 

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/