LWN: Comments on "ARM's multiply-mapped memory mess"

ARM's multiply-mapped memory mess

tiffang — Thu, 16 Dec 2010 03:52:43 +0000

I just think that the kernel can change the page's attribute at runtime.
flush dcaches, mmu entries.. then give that clean page to device drivers.
And rollback when device drivers give it back afterward.
Can it be possible?

ARM's multiply-mapped memory mess

mwh — Mon, 18 Oct 2010 20:19:03 +0000

It seems to be the cause of this bug, fwiw: https://bugs.edge.launchpad.net/ubuntu/+source/linux-lina...

ARM's multiply-mapped memory mess

oak — Sun, 17 Oct 2010 15:58:44 +0000

If it triggers user visible issues only rarely, in seemingly random circumstances (like some of the memory corruption bugs do) i.e. it's not reproducible, it's very well possible that nobody's identified what's causing "all those crashes", or that they're related.

ARM's multiply-mapped memory mess

marcH — Sun, 17 Oct 2010 13:04:03 +0000

> gets() is still in the C language,

... whereas ioremap() is a Linux internal.

> despite it being next to impossible to use safely.

... whereas using ioremap() safely is not a problem.

> Removing it is an API/ABI change.

... whereas no one suggests removing ioremap().

> In some ways, the situation with ARM's memory remapping sounds similar

Not really.

ARM's multiply-mapped memory mess

jzbiciak — Sat, 16 Oct 2010 22:33:11 +0000

gets() is still in the C language, despite it being next to impossible to use safely. But if you link against it, some platforms give you a big scary warning. If you're standards-conforming, you have to have it though. Removing it is an API/ABI change.

In some ways, the situation with ARM's memory remapping sounds similar: a dangerous practice that seems to work suitably, despite the potential for it to go pear shaped when you least expect.

ARM's multiply-mapped memory mess

gnb — Fri, 15 Oct 2010 22:17:44 +0000

That in turn depends on the licence: most of their customers (sorry, partners) licence an implementation. They get given either synthesizable code or a hard macro that implements the core (+MMU +cache as appropriate) to drop into their chip. Modulo bugs, all chips of this sort with the same core IP should behave the same. A few large partners (Marvell, Ti?) have architecture licences that cover changing the implementation provided it still matches the spec. . In those cases all bets are off for behaviour that the spec. doesn't define.

ARM's multiply-mapped memory mess

dlang — Fri, 15 Oct 2010 18:34:15 +0000

that depsnds on exactly how detailed the specs are. I believe that the ARM specs are not behavior (i.e. must implement these commands these ways), but are instead a much lower level (arrange logic gates in this way)

ARM's multiply-mapped memory mess

drag — Fri, 15 Oct 2010 12:53:30 +0000

One of the problems your going to face with ARM is that there is no one single implementation of the hardware, nor all the available hardware now is going to reflect all the hardware that is going to be.

ARM 6 is essentially a specification for a processor and not a real processor. Using the memory in the way the kernel does is 'unspecified'. It could work on today's processors made by Ti, but it could completely backfire on tomorrow's processors made by Marvel.

It's impossible to know and if it does start corrupting memory in the kernel then it's going to be 100% ok as far as the processor designers are concerned because they are still following the specification.

It's similar to having the kernel rely on unspecified GCC features were once a user chooses a GCC version they are forced to use it for ever and cannot change it no matter how badly it works with Linux.

ARM's multiply-mapped memory mess

felixfix — Thu, 14 Oct 2010 15:19:02 +0000

This puzzles me too. I guessed as marcH does, in the first answer to your question. It sure sounds spooky, but if it's been running this way for some time (years?), it must be one of those things that the manufacturer might want to use themselves someday for something different, so they put out a vague "undefined" warning while knowing that it does work.

ARM's multiply-mapped memory mess

marcH — Thu, 14 Oct 2010 15:08:33 +0000

> Furthermore, Russell's patch looks to them like an API change,..

Finally rejecting memory corruption is an API change? I can imagine such a logic backfiring and making his author not look serious.

ARM's multiply-mapped memory mess

marcH — Thu, 14 Oct 2010 15:00:10 +0000

The other possibility is that the behaviour "undefined" in the spec is actually very well defined in practice.

ARM's multiply-mapped memory mess

NAR — Thu, 14 Oct 2010 13:24:31 +0000

In a similar vein: my impression from the article is that there's been a memory corruption bug on the ARM architecture for at least half a year, yet nobody has been actually bit by it. Is there anybody who's actually using this kernel on version 6 ARM hardware?

ARM's multiply-mapped memory mess

dlang — Thu, 14 Oct 2010 06:42:24 +0000

warning for one cycle will do very little good. it generally takes longer than that for any distros to start using a kernel and get it into the hands of the users (and in the embedded space where ARM is so strong, it's even worse)

but even if it only took a week for a distro to QA and ship a kernel, and users started putting pressure on immediately, there is no chance for any development work to take place and still make it into the mainline kernel before the merge window closes.

it will probably take multiple kernel cycles before the warning is seen by any users who don't compile their own kernels, and then more time for the pressure from the users to build up, and then development time to fix the problem, and then time to merge the fixes upstream.

I don't see this taking place in less than a year, and probably a lot longer before everything is fixed.

Puzzled

ebiederm — Thu, 14 Oct 2010 06:24:45 +0000

With PAT on x86 we don't seem to have that limitation.

Can't the ARM guys just generalize the hard work that happened on x86 to guarantee to pages never get mapped to userspace with different attributes?

Followup

corbet — Thu, 14 Oct 2010 03:05:45 +0000

Since the article was posted, Linus has merged a patch re-enabling ioremap() on system RAM which emits a big, scary warning.