From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 6AC272C00B0 for ; Wed, 5 Sep 2012 05:41:08 +1000 (EST) Message-ID: <1346787647.3025.6.camel@pasglop> Subject: Re: 3.5+: yaboot, Invalid memory access From: Benjamin Herrenschmidt To: Michael Ellerman Date: Wed, 05 Sep 2012 05:40:47 +1000 In-Reply-To: <1346741491.7619.12.camel@concordia> References: <1346741491.7619.12.camel@concordia> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: Christian Kujau , linuxppc-dev@ozlabs.org, Steven Rostedt List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2012-09-04 at 16:51 +1000, Michael Ellerman wrote: > > My guess would be we're calling that quite early and the __put_user() > check is getting confused and failing. That means we'll have left some > code unpatched, which then fails. > > Can you try with the patch applied, but instead of returning if the > __put_user() fails, just continue on anyway. > > That will isolate if it's something in the __put_user() (I doubt it), > or > just that the __put_user() is failing and leaving the code unpatched. Bah, worse.... we do the feature fixups on 32-bit while still running unrelocated, so we need RELOC() macros everywhere. That's probably busted. We might be able to try replacing __put_user() with __put_user_size() to avoid the kernel address check, which is I think what's breaking it. That stuff has long been in my list of things to rework, ie, we do that fixup way too early on ppc32, in fact earlier than ppc64, ie, before the platform is probed which means the platform cannot adjust the bits. However, iirc, we have some early setup code that relies on the fixup being done that early so it's a bit of a chicken & egg problem that needs to be untangled first. Cheers, Ben.