lkml.org 
[lkml]   [2019]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
> Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
> > I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
> >
> > - patches 1 and 2 build and boot fine
> > - patches 3 to 6 build, but fail to boot with this error:
>
> The bug is in patch 2, mmu_mapin_ram() should return base instead of
> returning 0 when __map_without_bats is set.

Indeed, with this change, I can boot up to patch 11.

> > - patches 12 to 15 build but fail to boot with this error:
>
> Thats the one we need to really understand.
>
> Do you have modules ? If so, can you try without ?

I don't use any modules in my test setup, but I have module support
enabled. Disabling CONFIG_MODULES makes no difference, as far as I can
see (I get the same backtrace with memblock_alloc_base+0x34/0x44).

> > [ 0.000000] [c0f1ff30] [c00280f0] panic+0x144/0x324 (unreliable)
> > [ 0.000000] [c0f1ff90] [c0c18a34] memblock_alloc_base+0x34/0x44
> > [ 0.000000] [c0f1ffa0] [c0c071e0] MMU_init_hw+0xcc/0x300
> > [ 0.000000] [c0f1ffd0] [c0c06554] MMU_init+0x12c/0x198
> > [ 0.000000] [c0f1fff0] [c0003418] start_here+0x40/0x78

With a few printks[1], I traced this error, and got the following
result:

[ 0.000000] __memblock_find_range_top_down(1000:1800000, 100000:100000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13f00000
[ 0.000000] __memblock_find_range_top_down: in loop, 179962d:1800000
[ 0.000000] __memblock_find_range_top_down: in loop, 1676000:17987a0
[ 0.000000] __memblock_find_range_top_down: nothing found :(

The limit of 0x1800000 comes from setup_initial_memory_limit, which only
considers the first memblock, but the second memblock starts at 256MiB,
so it wouldn't be usable anyway, according to the comment in
setup_initial_memory_limit.

Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!


Jonathan

[1]:
diff --git a/mm/memblock.c b/mm/memblock.c
index 022d4cbb3618..66d588e08487 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -215,8 +215,11 @@ __memblock_find_range_top_down(phys_addr_t start, phys_addr_t end,
phys_addr_t this_start, this_end, cand;
u64 i;

+ printk("%s(%x:%x, %x:%x, %x, %x)\n", __func__, start, end, size, align, nid, flags);
+
for_each_free_mem_range_reverse(i, nid, flags, &this_start, &this_end,
NULL) {
+ printk("%s: in loop, %x:%x\n", __func__, this_start, this_end);
this_start = clamp(this_start, start, end);
this_end = clamp(this_end, start, end);

@@ -228,6 +231,7 @@ __memblock_find_range_top_down(phys_addr_t start, phys_addr_t end,
return cand;
}

+ printk("%s: nothing found :(\n", __func__);
return 0;
}
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-01-16 01:35    [W:0.112 / U:3.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site