From: jlinton@redhat•com (Jeremy Linton)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] [PATCH] arm64: Boot failure on m400 with new cont PTEs
Date: Mon, 23 Nov 2015 10:02:02 -0600 [thread overview]
Message-ID: <5653387A.2000101@redhat.com> (raw)
In-Reply-To: <20151123155132.GC32300@e104818-lin.cambridge.arm.com>
On 11/23/2015 09:51 AM, Catalin Marinas wrote:
> Call trace:
> [<ffffffc0000952b8>] __create_mapping.isra.5+0x360/0x530
> [<ffffffc0000954ec>] fixup_init+0x64/0x80
> [<ffffffc0000945a4>] free_initmem+0xc/0x38
> [<ffffffc0005eb9f8>] kernel_init+0x20/0xe0
> [<ffffffc000085c50>] ret_from_fork+0x10/0x40
>
> What I don't get is why we have fixup_init() even when
> !CONFIG_DEBUG_RODATA. It probably breaks the initial mapping just to get
> a non-executable init section. However, the other sections are left
> executable when this config option is disabled. The patch below fixes
> the warnings above:
Well the kernel permissions are a bit of a mess, and not at all
"secure" in their current state. But I guess the thought must have been
that turning off execute on the init sections was a good way to find
functions incorrectly marked _init(). Which is different from RO.
Frankly, I expect someone will push to cleanup the kernel permissions at
some point (I've got it on my "spare time todo, list"), but this will of
course make the create_mapping_late a lot more popular as I see it being
called during module load/unload.
Anyway, I've been saying the problem is create_mapping_late() all
along, as you notice there isn't any TLB flushes in fixup_init() and
that is the core of the problem, not all this other discussion.
> Jeremy, can you give this fixup_init() patch a try, see whether it makes
> any difference (it's just a temporary hack which may prevent us from
> reverting the PTE_CONT patches until we have a better solution).
I will try it, but i'm pretty sure that fixes it too.
next prev parent reply other threads:[~2015-11-23 16:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 15:03 [PATCH] [PATCH] arm64: Boot failure on m400 with new cont PTEs Jeremy Linton
2015-11-18 15:20 ` Mark Rutland
2015-11-18 16:08 ` Jeremy Linton
2015-11-18 16:29 ` Mark Rutland
2015-11-18 17:14 ` Jeremy Linton
2015-11-18 18:04 ` Mark Rutland
2015-11-18 19:31 ` Jeremy Linton
2015-11-19 11:31 ` Mark Rutland
2015-11-20 19:52 ` Mark Rutland
2015-11-23 12:15 ` Catalin Marinas
2015-11-23 13:49 ` Mark Rutland
2015-11-23 14:48 ` Jeremy Linton
2015-11-23 15:41 ` Will Deacon
2015-11-23 15:46 ` Jeremy Linton
2015-11-23 14:31 ` Jeremy Linton
2015-11-20 20:15 ` Mark Rutland
2015-11-23 15:51 ` Catalin Marinas
2015-11-23 16:02 ` Jeremy Linton [this message]
2015-11-23 16:37 ` Laura Abbott
2015-11-23 16:42 ` Jeremy Linton
2015-11-23 17:52 ` Laura Abbott
2015-11-23 18:46 ` Jeremy Linton
2015-11-24 8:04 ` Ard Biesheuvel
2015-11-23 16:52 ` Catalin Marinas
2015-11-23 17:24 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5653387A.2000101@redhat.com \
--to=jlinton@redhat$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox