linux-kernel - Re: [PATCH 7/8] x86/mrst: add vrtc driver which serves as a wall clock device

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: <alpine.LFD.2.00.1005182257030.3368@localhost.localdomain>
Date:	Tue, 18 May 2010 23:02:56 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	john stultz <johnstul@...ibm.com>
cc:	Feng Tang <feng.tang@...el.com>,
	Jacob Pan <jacob.jun.pan@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	"Du, Alek" <alek.du@...el.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/8] x86/mrst: add vrtc driver which serves as a wall
 clock device

On Tue, 18 May 2010, john stultz wrote:

> On Mon, 2010-05-17 at 11:15 +0200, Thomas Gleixner wrote:
> > 
> > 
> > There is no particular reason why we need to read it in
> > timekeeping_init(). Nothing in the kernel needs the correct wall time
> > at that point. So we can safely move the setting of xtime to rtc wall
> > clock time to a separate timekeeping_late_init() function.
> > 
> > John ???
> 
> No big objections here. Still would like to keep the amount of time that
> the kernel is up without xtime being initialized to a minimum. However

Why? Nothing _IS_ depending on xtime at this point. We just should
have it ready when we mount the first file system, but even that is
not a big issue aside of some stupid warnings.

> the generic RTC code already have this issue since some of them require
> interrupts to be enabled to do a read, so pushing it off into a
> _late_init() function is probably just a short term fix until we figure
> out how to get the generic RTC code working better with the timekeeping
> code.

Well, you need to wait until the driver is loaded and the hardware
accessible which might take some time when I2C, SPI or similar stuff
is involved. No way to get this stuff accesible early.

So really the question is, why do we want wall time initialized early?
All we care about until we hit user space is clock monotonic and
working timekeeping in general. NTP is not an issue either before we
hit user space. So what's your concern ?

> Does the delayed init required by vrtc cause any trouble with
> suspend/resume?

No, suspend/resume does not go through that early code. It has
everything setup (mappings, etc)

Thanks,

	tglx

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