KASAN/pcpu_alloc related panics on v6.0

[Atish Patra]

Hi All,
Palmer reported some KASAN/pcpu_alloc related panics on v6.0. Here is
one of them

[   39.350391] Unable to handle kernel paging request at virtual
address ffebfffeffff3000
[   39.354419] Oops [#1]
[   39.355081] Modules linked in:
[   39.356203] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0 #36
[   39.357621] Hardware name: riscv-virtio,qemu (DT)
[   39.358773] epc : kasan_check_range+0x9e/0x14e
[   39.361299]  ra : memset+0x1e/0x4c
[   39.362118] epc : ffffffff8030c1f8 ra : ffffffff8030c936 sp :
ff60000003367a80
[   39.363114]  gp : ffffffff82388b40 tp : ff60000003358000 t0 :
ffebffff009d977c
[   39.364264]  t1 : ffebfffeffff301f t2 : ffffffff80783bf6 s0 :
ff60000003367ab0
[   39.365584]  s1 : 0000000000000100 a0 : ffebfffeffff3020 a1 :
0000000000000100
[   39.366538]  a2 : 0000000000000001 a3 : ffffffff802954bc a4 :
ff5ffffffff98000
[   39.367493]  a5 : ffebfffeffff3000 a6 : 0000000400000000 a7 :
ff5ffffffff980ff
[   39.368864]  s2 : ff5ffffffff98000 s3 : 0000000000000000 s4 :
ff6000003fdf1b00
[   39.370208]  s5 : ff600000041b9b38 s6 : ffffffff8238b600 s7 :
0000000000000008
[   39.371168]  s8 : ffffffff823a4060 s9 : 0000000000000000 s10:
ff5ffffffff98000
[   39.372330]  s11: 0000000000000100 t3 : 0000000000000000 t4 :
0000000000000004
[   39.373444]  t5 : ffebfffeffff3020 t6 : 0000000000000003
[   39.374205] status: 0000000200000120 badaddr: ffebfffeffff3000
cause: 000000000000000d
[   39.375783] [<ffffffff802954bc>] pcpu_alloc+0x4c8/0xac4
[   39.377520] [<ffffffff80295ae4>] __alloc_percpu+0x14/0x1c
[   39.378336] [<ffffffff806b30f8>] blk_mq_init_allocated_queue+0xfc/0x87c
[   39.379294] [<ffffffff806b4b00>] __blk_mq_alloc_disk+0x62/0xbc
[   39.380397] [<ffffffff808e03ec>] loop_add+0x24a/0x4fa
[   39.381472] [<ffffffff81033e26>] loop_init+0xfe/0x122
[   39.382394] [<ffffffff80002e2a>] do_one_initcall+0xda/0x460
[   39.383369] [<ffffffff8100166c>] kernel_init_freeable+0x39c/0x404
[   39.384722] [<ffffffff80e7b890>] kernel_init+0x20/0x122
[   39.385605] [<ffffffff8000492e>] ret_from_exception+0x0/0x10
[   39.389031] ---[ end trace 0000000000000000 ]---


This one is easily reproducible with the following additional config enabled.

$ cat configs/linux/kasan_provelock
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_KASAN=y
# CONFIG_KASAN_VMALLOC is not set
CONFIG_STRICT_KERNEL_RWX=y

This issue has been there since v5.18. v5.17 works fine though.
Git bisection pointed to a wrong powerpc commit probably because of
the following reason.

RISC-V v5.18 merge window PR was based on v5.17-rc1 which had other
similar kasan issues w.r.to sv48
which confused the bisect. But v5.17 works fine because the issues
were fixed as a part of late PR on top of v5.17-rc7
(https://lore.kernel.org/lkml/164642532157.24805.457490534031372221.pr-tracker-bot@kernel.org/T/)

Inspecting the RISC-V commits manually on 5.18-rc1(also fails) seems
to indicate that there is probably a cause.

Enabling sv57 with kasan triggers this panic. I verified that in two ways.

1. Reverted the below sv57 patches from 5.18-rc1 and it boots fine.

8fbdccd2b173 riscv: mm: Support kasan for sv57
011f09d12052 riscv: mm: Set sv57 on defaultly
677b9eb8810e riscv: mm: Prepare pt_ops helper functions for sv57
d10efa21a937 riscv: mm: Control p4d's folding by pgtable_l5_enabled

2. Disabled sv57 in Qemu on v6.0 and it boots fine.

I am yet to find out the exact fix that would solve the panic pointed
out by Kasan on sv57 though.
@Alexandre Ghiti Is it possible for you to take a look ?

-- 
Regards,
Atish