linux-kernel - Re: [RFC][patch 00/12] clocksource / timekeeping rework V2

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1248973973.3331.2.camel@work-vm>
Date:	Thu, 30 Jul 2009 10:12:53 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:	dwalker@...o99.com, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][patch 00/12] clocksource / timekeeping rework V2

On Thu, 2009-07-30 at 12:53 +0200, Martin Schwidefsky wrote:
> On Wed, 29 Jul 2009 11:17:16 -0600
> dwalker@...o99.com wrote:
> 
> > On Wed, 2009-07-29 at 19:09 +0200, Martin Schwidefsky wrote:
> > > On Wed, 29 Jul 2009 11:02:21 -0600
> > > dwalker@...o99.com wrote:
> > > 
> > > > On Wed, 2009-07-29 at 18:50 +0200, Martin Schwidefsky wrote:
> > > > 
> > > > > void clocksource_change_rating(struct clocksource *cs, int rating)
> > > > 
> > > > > the two functions do different things. What exactly is the idea you've
> > > > > got in mind?
> > > > 
> > > > It's only the case when the rating goes to zero .. That makes the
> > > > clocksource unusable, which is very much like unregistering it..
> > > 
> > > True, the clocksource code won't pick the clock any more as long as
> > > there is an alternative clock available. It still shows up in the list
> > > of clocks though and you can do an override with it. 
> > 
> > I'm not sure allowing that type of override a good idea tho .. I don't
> > think it's considered a usable clock when the rating goes to zero.
> 
> Override as the root user -> your foot, no? The whole override stuff is
> there for the case that the clocksource selection picked a broken clock
> and you want to force the system into a semi-working state. Ideally the
> whole override would go away, but that is probably wishful thinking..

Its also not only for when a system is broken, but quite often is used
when the system selects a slower clocksource out of caution and the user
wants to override that decision. The kernel really should get it right,
but there is always the case of an old kernel on new hardware that might
require it. 

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/