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:	Thu, 09 Dec 2010 09:45:46 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	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 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.

So we'd probably need to move that to a different (early) arch callback
if time_init is moved.

Also, still on server PPC, you can't really disable the decrementer
(only delay it). So if interrupts are enabled, we will eventually get
timer ones.

So we'd have to be careful about keeping some state, knowing that the
stuff isn't initialized yet and just set the decrementer to fire again
as late as possible, until it's properly configured.

Besides, we can use kmalloc that early nowadays, can't we ? That's what
the gfp_allowed_mask is all about ...

Cheers,
Ben.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ