linux-kernel - Re: Boot failure with next-20120208

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: <1332541090.2882.14.camel@pasglop>
Date:	Sat, 24 Mar 2012 09:18:10 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Michael Neuling <mikey@...ling.org>,
	gregkh@...uxfoundation.org, LKML <linux-kernel@...r.kernel.org>,
	Milton Miller <miltonm@....com>, linux-next@...r.kernel.org,
	ppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: Boot failure with next-20120208

On Fri, 2012-03-23 at 12:24 -0700, Arjan van de Ven wrote:
> well yeah, PPC is throwing things in the spanner
> 
> we're now working on an x86-only patch with basically the same
> improvement, but done in a way that does not touch the other
> architectures
> 
> so by all means drop the patch

Or maybe make an arch flag to enable the behaviour ? I can have a look
at the problem & maybe even fix it next week (it's been under my radar
for some reason so far), but I know at least of a few places where we
have that sort of assumptions about the bringup of boot CPUs.

For example, on Apple G5s, we don't support real hotplug, so the hot
unplug path just puts them in a linux-controlled sleep loop. So the
early boot time bringup is different from the hotplug path. 

Among others, it needs access to things like i2c to synchronize the time
bases of the CPUs being brought up and we "release" that resource at the
end of the bringup.

So that needs fixing a way or another (and it's non trivial as other
drivers might try to get a lock on that i2c bus).

I'm sure I have a few other places with similar assumptions. And I
wouldn't be surprised if other architectures do as well :-)

So while your patch is a good / worthwhile idea, I think we need a bit
more time to sort things out before it can be applied.

(BTW. Arjan, can you send me privately your latest version of that
patch, for some reason I don't seem to be able to put my hand on it).

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/