On Thu, 2 Jul 2020 at 00:28, Florian Fainelli [off-list ref] wrote:

On 7/1/2020 2:41 PM, Ard Biesheuvel wrote:

quoted

On Wed, 1 Jul 2020 at 22:16, Florian Fainelli [off-list ref] wrote:

quoted

On 7/1/2020 5:09 AM, Ard Biesheuvel wrote:

quoted

I pushed these changes and a few more to

https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kasan-v11

This branch works a bit better however I am still seeing some boot
errors (some sample logs attached) similar to Linus' branch.

These crashes are all identical, they all crash on the bc9ffe00 shadow
address not being backed by early shadow memory.

That value has all bits PTE index bits set to 1, and given how
memblock usually allocates top down, it means we are allocating page
by page and calling check_memory_region() on it during the memset()
until the point where we hit a PMD that is not set, covering the
window bc800000-bc9fffff

Are there any memory reservations in the range ec000000-ecffffff ?

Not that I can see according to memblock=debug:

Yeah I actually meant the PA equivalent of that, i.e., 2c000000-2cffffff

[    0.000000]  reserved.cnt  = 0x6
[    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
0x0000000000001000 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
0x0000000000005000 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
0x0000000002bd0b80 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000065fffff],
0x0000000000200000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x000000000e415000-0x000000000e41960b],
0x000000000000460c bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x000000007f000000-0x000000007fffffff],
0x0000000001000000 bytes flags: 0x0

[    0.000000]  reserved.cnt  = 0x7
[    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
0x0000000000001000 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
0x0000000000005000 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
0x0000000002bd0b80 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000064fffff],
0x0000000000100000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x0000000007008000-0x000000000700ffff],
0x0000000000008000 bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x0000000007819000-0x000000000781e5cf],
0x00000000000055d0 bytes flags: 0x0
[    0.000000]  reserved[0x6]   [0x000000003cc00000-0x000000003dbfffff],
0x0000000001000000 bytes flags: 0x0

quoted

Are you using the default vmalloc range?

Yes.

quoted

Any other peculiarities in the memory layout?

Not that I can think of, the memory is mapped at PA 0x0000_0000 all the
way to 0xbfff_ffff and then all other memory is mapped at PA
0x1_0000_0000 and aboved.

OK, so assuming kasan_early_init() backs the entire shadow region with
zero pages correctly, we are losing the mapping somewhere between
there and kasan_init(), and there are quite a number of
create_mapping() calls in the meantime.

So if you have cycles to spend on this, do you mind instrumenting
create_mapping() and see whether any of the ranges that are
(re`)mapped come within 2 MB of bc800000-bc9fffff?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel