linux-kernel - Re: [PATCH] Introduce mips_late_time

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] [day] [month] [year] [list]

Message-ID: <20101210172125.GA3750@linux-sh.org>
Date:	Sat, 11 Dec 2010 02:21:25 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ralf Baechle <ralf@...ux-mips.org>,
	David Daney <ddaney@...iumnetworks.com>,
	Anoop P A <anoop.pa@...il.com>, linux-mips@...ux-mips.org,
	LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Introduce mips_late_time_init

On Thu, Dec 09, 2010 at 09:45:46AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2010-12-08 at 22:21 +0100, Thomas Gleixner wrote:
> > On Wed, 8 Dec 2010, Ralf Baechle wrote:
> > > Running everything from late_time_init() instead allows the use of kmalloc.
> > > X86 has the same issue with requiring kmalloc in time_init which is why
> > > they had moved everything to late_time_init.
> > 
> > It's more ioremap, but yeah.
> >  
> > > So the real question is, why can't we just move the call of time_init()
> > > in setup_kernel() to where late_time_init() is getting called from for
> > > all architectures, does anything rely on it getting called early?
> > 
> > That's a good question and I asked it myself already. I can't see a
> > real reason why something would need it early. Definitely worth to
> > try.
> 
> Well, I can see some reasons at least...
> 
> On ppc at least, we calibrate the timebase/decrementer in time_init, so
> things like udelay etc... are going to be unreliable until we've done
> that, which could be a problem if done too late due to sensitive HW
> accessors that might rely on these.
> 
The SH case is similar. We bring up the clock framework during
time_init() which we need for per-CPU loops_per_jiffy calculation in
addition to initializing the clocksource/clockevent timers that come up
during late_time_init.

Presently we have a slab_is_available() check in the SH clkdev
implementation mostly for board PLLs and so on, and our ioremap()
implementation also transparently bolts on to fixed ioremaps through
fixmap if we're really early anyways. It's possible that kmalloc is
usable outright now after the reordering happened, I haven't gone back
and checked it again since then.

> So we'd probably need to move that to a different (early) arch callback
> if time_init is moved.
> 
late_time_init has always struck me as a bit of a misnomer, since it's
still quite early as far as the rest of the system state is concerned,
particularly the driver core (all SH and ARM SH-Mobile platforms use
platform devices for clocksources/clockevents). In any event, SH would
also need this.

On ARM SH-Mobile we use the same approach although each platform
explicitly calls in to clock framework initialization prior to assigning
a late_time_init, which in turn gets all wrapped up in the ARM sys_timer
abstraction.
--
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/