linux-kernel - Re: [PATCH v2 08/12] ARM: allow MULTIPLATFORM with !MMU

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]

Message-ID: <1622755.AGsAr84gTH@wuerfel>
Date:	Tue, 30 Dec 2014 23:27:20 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Stefan Agner <stefan@...er.ch>
Cc:	Rob Herring <robherring2@...il.com>,
	Shawn Guo <shawn.guo@...aro.org>, kernel@...gutronix.de,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Olof Johansson <olof@...om.net>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Marc Zyngier <marc.zyngier@....com>,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 08/12] ARM: allow MULTIPLATFORM with !MMU

On Tuesday 30 December 2014 23:02:31 Stefan Agner wrote:
> On 2014-12-30 22:42, Rob Herring wrote:
> > On Mon, Dec 29, 2014 at 5:32 PM, Stefan Agner <stefan@...er.ch> wrote:
> >> @@ -783,13 +780,13 @@ comment "CPU Core family selection"
> >>
> >>  config ARCH_MULTI_V4
> >>         bool "ARMv4 based platforms (FA526)"
> >> -       depends on !ARCH_MULTI_V6_V7
> >> +       depends on !ARCH_MULTI_V6_V7 && MMU
> > 
> > This is not right. !MMU does not mean the ARM arch does not have an
> > MMU, but rather the MMU is already setup with identity mapping (or
> > some other static mapping).
> 
> Yes, I'm aware of that. However, there are several configuration
> depending on "!MMU". Allowing !MMU on ARCH_MULTI_V4...V7 would open up
> new combination of configurations... This patch avoids this as much as
> possible, by making !MMU only available for ARCH_MULTI_V7M.
> 
> I'm not sure what tests/verification would be expected before allowing
> those new configurations... Personally, I also don't see much value in
> allowing these configurations.

There is a much bigger question to be answered here. Traditionally we
have allowed non-MMU configurations for all platforms, but with the
introduction of multiplatform support, that was implicitly dropped
for each platform that got converted. This was not really intended, but
we also never got complaints from users that were missing functionality
as a result of this.

In 3.19, we have also removed support for the last ARMv4 platform that
did not have an MMU (Atmel at91x40), so now we have four classes of
nommu systems remaining:

a) ARMv7-M: Cortex-M3 and M4 based platforms. We definitely need to
   support these, as that is the entire point of your series and other
   users want it too.

b) ARMv7-R and ARMv7-A with MMU disabled: This is almost supported by
   the kernel, except we don't have any platform using it. ARMv7-R
   support is probably useful if anybody invests the time to make it
   work, and being able to test those kernels on ARMv7-A hardware also
   seems worthwhile.

c) Out of mainline ARMv4t/ARMv5 platforms (based on arm7tdmi, arm9tdmi,
   arm9e, arm740t, arm940t, arm946e, or some unsupported Faraday or
   Marvell core), in theory also ARM Integrator with the respective
   core tiles. It may just be time now to remove this support from the
   kernel, as practically everyone with those cores is already stuck
   on ancient kernels, maybe with the exception of Russell's OKI platform
   port.
   I've asked around at conferences among people that are still interested
   in NOMMU hardware in general, and apparently running modern kernels
   on this class of hardware isn't interesting to anyone I found.

c) Any other hardware with MMU disabled. I personally don't see a reason
   to keep it, but maybe I'm just not creative enough. I have an old
   patch series to get this to compile for random configurations that
   are currently broken. If we keep this enabled, we should at least
   get allmodconfig with MMU disabled to build.

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