linux-kernel - Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision

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:	Mon, 16 Mar 2015 19:21:52 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Tony Lindgren <tony@...mide.com>, Pavel Machek <pavel@....cz>,
	Pali Rohár <pali.rohar@...il.com>,
	Rob Herring <robherring2@...il.com>,
	Will Deacon <will.deacon@....com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Sebastian Reichel <sre@...ian.org>,
	Andreas Färber <afaerber@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision

On Mon, Mar 16, 2015 at 12:43:47PM -0400, Nicolas Pitre wrote:
> Your publicly visible tree contains only a few mundane patches.
> Is that the tree you're testing with?  If no then could you publish it 
> for others to have a look and test?

Okay, having investigated three cases of this, ended up mostly at
dead-ends, and having talked to Will, I think the conclusion is that
no one really understands what's going on here. :p

A number of people (including people within ARM) have seen the problem
that I've seen with a variety of kernel versions, including versions
which I haven't seen a problem with.

My own investigations turn up patches which don't have that much to do
with the SMP booting itself: yes, one was a L2C patch, but I've had
that for a very long time.  The FIQ changes for the GIC which shouldn't
have affected it.  Olof's MMC patches to support resets and regulators
which we don't even get to, so couldn't affect it /code-wise/.

What all these have in common is an influence on the layout of the
kernel image.  Exactly what that is, I don't know yet - I've not had
the time to be able to investigate that deeply as I've been trying to
characterise the failure and track it down to an easy "this works,
this doesn't" test case.  I now have that with a kernel without MMC
changes vs a kernel with MMC changes - where I know that the actual
changes have nothing to do with the problem itself.

There's only one person (not me) who has been able to get a reasonable
amount of debug so far - Sudeep (@arm) has found that both CPU0 and CPU1
are stuck in the radix code, but merely using the debugger "frees" them
from there.

Now that I'm aware that _others_ are or have seen the same issue I am,
I can worry slightly less about the issue... and what it confirms to
me is that it's less about what the kernel code is, more about the
placement of kernel code.

The unfortunate side effect is that it cuts down on the amount of useful
testing I can do prior to sending stuff to Linus... but C'est la vie.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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/