linux-kernel - Re: + clocksource-increase-initcall-priority.patch added to -mm tree

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: <1160323127.5686.37.camel@localhost.localdomain>
Date:	Sun, 08 Oct 2006 17:58:46 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	akpm@...l.org, johnstul@...ibm.com, mingo@...e.hu,
	zippel@...ux-m68k.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: + clocksource-increase-initcall-priority.patch added to -mm
	tree

On Sun, 2006-10-08 at 08:45 -0700, Daniel Walker wrote:
> > I'd like to know, why we need to move that and you did not explain _why_
> > it is likely that it is used during bootup.
> 
> If the clocksources are registered at the same time as the clocksource
> users then you end up with users frequently switching clocks during boot
> up. The original clocksource code solved this by not allowing a real
> clocksource lookup until after the system fully booted.

No, that was not the reason. It does not hurt anything, when the
clocksource changes during bootup. You simply replace one read out
device by another one.

The reason was that we wanted to select clocksources as late as
possible, as we wanted to have late init clocksources ready and TSC
problems outruled.

> However, if you put all the clocksources into postcore initcall, with
> that being known in advance, and all the users are in lower priority
> initcalls then you don't need extra code to prevent churn during bootup.
> 
> The reason that I think this will get used during boot up is because
> some of the target users will be instrumentation, and (my prediction
> anyway) is that some will need to use the interface early. Still even
> postcore may not be early enough.

Early bootup Instrumentation is really not a good argument to make that
fragile time related stuff even more complex. There is no problem to
register reliable clocksources in early bootup, but do not make this
mandatory. Not every system is an ARM SoC, where you can and must rely
on the one source which is available usually right when the CPU comes
up.

Early bootup instrumentation can very well go with none or coarse
grained time information, if there is a need to have early boot
intstrumentation at all.

	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/