System is broken in KASAN sw_tags mode during bootup

[Baoquan He]

Hi,

This can be reproduced stably on hpe-apollo arm64 system with the latest
upstream kernel. I have this system at hand now, the boot log and kernel
config are attached for reference.

[ 89.257633] ==================================================================
[ 89.257646] BUG: KASAN: invalid-access in pcpu_alloc_noprof+0x42c/0x9a8
[ 89.257672] Write of size 528 at addr ddfffd7fbdc00000 by task systemd/1
[ 89.257685] Pointer tag: [dd], memory tag: [ca]
[ 89.257692]
[ 89.257703] CPU: 108 UID: 0 PID: 1 Comm: systemd Not tainted 6.17.0-rc2 #1 PREEMPT(voluntary)
[ 89.257719] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.16 07/29/2020
[ 89.257726] Call trace:
[ 89.257731] show_stack+0x30/0x90 (C)
[ 89.257753] dump_stack_lvl+0x7c/0xa0
[ 89.257769] print_address_description.isra.0+0x90/0x2b8
[ 89.257789] print_report+0x120/0x208
[ 89.257804] kasan_report+0xc8/0x110
[ 89.257823] kasan_check_range+0x7c/0xa0
[ 89.257835] __asan_memset+0x30/0x68
[ 89.257847] pcpu_alloc_noprof+0x42c/0x9a8
[ 89.257859] mem_cgroup_alloc+0x2bc/0x560
[ 89.257873] mem_cgroup_css_alloc+0x78/0x780
[ 89.257893] cgroup_apply_control_enable+0x230/0x578
[ 89.257914] cgroup_mkdir+0xf0/0x330
[ 89.257928] kernfs_iop_mkdir+0xb0/0x120
[ 89.257947] vfs_mkdir+0x250/0x380
[ 89.257965] do_mkdirat+0x254/0x298
[ 89.257979] __arm64_sys_mkdirat+0x80/0xc0
[ 89.257994] invoke_syscall.constprop.0+0x88/0x148
[ 89.258011] el0_svc_common.constprop.0+0x78/0x148
[ 89.258025] do_el0_svc+0x38/0x50
[ 89.258037] el0_svc+0x3c/0x168
[ 89.258050] el0t_64_sync_handler+0xa0/0xf0
[ 89.258063] el0t_64_sync+0x1b0/0x1b8
[ 89.258076]
[ 89.258080] The buggy address belongs to a 0-page vmalloc region starting at 0xcafffd7fbdc00000 allocated at pcpu_get_vm_areas+0x0/0x1da0
[ 89.258111] The buggy address belongs to the physical page:
[ 89.258117] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x881ddac
[ 89.258129] flags: 0xa5c00000000000(node=1|zone=2|kasantag=0x5c)
[ 89.258148] raw: 00a5c00000000000 0000000000000000 dead000000000122 0000000000000000
[ 89.258160] raw: 0000000000000000 f3ff000813efa600 00000001ffffffff 0000000000000000
[ 89.258168] raw: 00000000000fffff 0000000000000000
[ 89.258173] page dumped because: kasan: bad access detected
[ 89.258178]
[ 89.258181] Memory state around the buggy address:
[ 89.258192] Unable to handle kernel paging request at virtual address ffff7fd7fbdbffe0
[ 89.258199] KASAN: probably wild-memory-access in range [0xfffffd7fbdbffe00-0xfffffd7fbdbffe0f]
[ 89.258207] Mem abort info:
[ 89.258211] ESR = 0x0000000096000007
[ 89.258216] EC = 0x25: DABT (current EL), IL = 32 bits
[ 89.258223] SET = 0, FnV = 0
[ 89.258228] EA = 0, S1PTW = 0
[ 89.258232] FSC = 0x07: level 3 translation fault
[ 89.258238] Data abort info:
[ 89.258241] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
[ 89.258246] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 89.258252] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 89.258260] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000008ff8b8f000
[ 89.258267] [ffff7fd7fbdbffe0] pgd=1000008ff0275403, p4d=1000008ff0275403, pud=1000008ff0274403, pmd=1000000899079403, pte=0000000000000000
[ 89.258296] Internal error: Oops: 0000000096000007 [#1] SMP
[ 89.540859] Modules linked in: i2c_dev
[ 89.544619] CPU: 108 UID: 0 PID: 1 Comm: systemd Not tainted 6.17.0-rc2 #1 PREEMPT(voluntary)
[ 89.553234] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.16 07/29/2020
[ 89.562970] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 89.569933] pc : __pi_memcpy_generic+0x24/0x230
[ 89.574472] lr : kasan_metadata_fetch_row+0x20/0x30
[ 89.579350] sp : ffff8000859d76c0
[ 89.582660] x29: ffff8000859d76c0 x28: 0000000000000100 x27: ffff008ec626d800
[ 89.589807] x26: 0000000000000210 x25: 0000000000000000 x24: fffffd7fbdbfff00
[ 89.596952] x23: ffff8000826cbeb8 x22: fffffd7fbdc00000 x21: 00000000fffffffe
[ 89.604097] x20: ffff800082682ee0 x19: fffffd7fbdbffe00 x18: 00000000049016ff
[ 89.611242] x17: 3030303030303030 x16: 2066666666666666 x15: 6631303030303030
[ 89.618386] x14: 0000000000000001 x13: 0000000000000001 x12: 0000000000000001
[ 89.625530] x11: 687420646e756f72 x10: 0000000000000020 x9 : 0000000000000000
[ 89.632674] x8 : ffff78000859d766 x7 : 0000000000000000 x6 : 000000000000003a
[ 89.639818] x5 : ffff8000859d7728 x4 : ffff7fd7fbdbfff0 x3 : efff800000000000
[ 89.646963] x2 : 0000000000000010 x1 : ffff7fd7fbdbffe0 x0 : ffff8000859d7718
[ 89.654107] Call trace:
[ 89.656549] __pi_memcpy_generic+0x24/0x230 (P)
[ 89.661086] print_report+0x180/0x208
[ 89.664753] kasan_report+0xc8/0x110
[ 89.668333] kasan_check_range+0x7c/0xa0
[ 89.672258] __asan_memset+0x30/0x68
[ 89.675836] pcpu_alloc_noprof+0x42c/0x9a8
[ 89.679935] mem_cgroup_alloc+0x2bc/0x560
[ 89.683947] mem_cgroup_css_alloc+0x78/0x780
[ 89.688222] cgroup_apply_control_enable+0x230/0x578
[ 89.693191] cgroup_mkdir+0xf0/0x330
[ 89.696771] kernfs_iop_mkdir+0xb0/0x120
[ 89.700697] vfs_mkdir+0x250/0x380
[ 89.704103] do_mkdirat+0x254/0x298
[ 89.707596] __arm64_sys_mkdirat+0x80/0xc0
[ 89.711697] invoke_syscall.constprop.0+0x88/0x148
[ 89.716491] el0_svc_common.constprop.0+0x78/0x148
[ 89.721286] do_el0_svc+0x38/0x50
[ 89.724602] el0_svc+0x3c/0x168
[ 89.727746] el0t_64_sync_handler+0xa0/0xf0
[ 89.731933] el0t_64_sync+0x1b0/0x1b8
[ 89.735603] Code: f100805f 540003c8 f100405f 540000c3 (a9401c26)
[ 89.741695] ---[ end trace 0000000000000000 ]---
[ 89.746308] note: systemd[1] exi
=========================

[Andrey Konovalov]

Might be the same issue as the one being fixed by Maciej here:

https://lore.kernel.org/all/bcf18f220ef3b40e02f489fdb90fc7a5a153a3...@intel.com/
https://lore.kernel.org/all/3339d11e69c9127108fe8ef80a069b7b3bb071...@intel.com/

Perhaps it makes sense to split that fix out of the series and submit
separately.

[Baoquan He]

Thanks for the information. I finally got a machine to reproduce the
issue and testing the patches. It's weird it firstly can't be reproduced
in the latest 6.17.0-rc5+, not sure if I made anything wrong on steps.
Later, I started it over and can stably reproduce the problem, I can
confirm Maciej's two patches can fix the problem very well.

Will reply to Maciej's patches to add my Tested-by.

Thanks
Baoquan