[ 426.327837] The buggy address belongs to the object at ffff883ff7c1e780 which belongs to the cache kmalloc-8 of size 8
[ 426.338289] The buggy address is located 0 bytes inside of 8-byte region [ffff883ff7c1e780, ffff883ff7c1e788)
[ 426.348805] The buggy address belongs to the page:
[ 426.354223] page:ffffea00ffdf0780 count:1 mapcount:0 mapping: (null) index:0x0
[ 426.359838] flags: 0x57ffffc0000100(slab)
[ 426.365373] raw: 0057ffffc0000100 0000000000000000 0000000000000000 0000000100aa00aa
[ 426.371135] raw: dead000000000100 dead000000000200 ffff8817f500fb80 0000000000000000
[ 426.377004] page dumped because: kasan: bad access detected
[ 426.388626] Memory state around the buggy address:
[ 426.394498] ffff883ff7c1e680: fc fc 00 fc fc fb fc fc 00 fc fc fb fc fc 00 fc
[ 426.400634] ffff883ff7c1e700: fc 00 fc fc fb fc fc 00 fc fc fb fc fc fb fc fc
[ 426.406721] >ffff883ff7c1e780: fb fc fc fb fc fc fb fc fc 00 fc fc fb fc fc fb
[ 426.412737] ^
[ 426.418698] ffff883ff7c1e800: fc fc fb fc fc fb fc fc fb fc fc fb fc fc fb fc
[ 426.424961] ffff883ff7c1e880: fc 00 fc fc fb fc fc fb fc fc fb fc fc fb fc fc
[ 426.431154] ==================================================================
[ 426.437413] Disabling lock debugging due to kernel taint
[ 426.472795] IRQ 8: no longer affine to CPU31
[ 426.472806] IRQ 9: no longer affine to CPU31
[ 426.472827] IRQ 40: no longer affine to CPU31
[ 426.473962] smpboot: CPU 31 is now offline
I ran it several more times without any obvious errors; however, I might have missed something. (The dmesg output is quite verbose and scrolls by quickly!)
Joseph,
The first run of your latest kernel completed; however, I noticed the following in the dmesg output:
[ 426.281083] ======= ======= ======= ======= ======= ======= ======= ======= ======= === bit+0x1f/ 0x80
[ 426.286615] BUG: KASAN: use-after-free in find_first_
[ 426.291841] Read of size 8 at addr ffff883ff7c1e780 by task cpuhp/31/195
[ 426.302209] CPU: 31 PID: 195 Comm: cpuhp/31 Not tainted 4.13.0-25-generic #29~lp1733662KA SANenabled M4L/UCSC- C240-M4L, BIOS C240M4. 2.0.10c. 0.032320160820 03/23/2016 0xb8/0x12d map_sg+ 0xd3/0xd3 print_info+ 0x41/0x41 description+ 0x6f/0x280 0x27a/0x370 bit+0x1f/ 0x80 load8+0x54/ 0x90 bit+0x1f/ 0x80 rmid+0x47/ 0x70 offline_ cpu+0x4b4/ 0x510 rmid.isra. 4+0x70/ 0x70 group+0x7a/ 0xc0 rmid.isra. 4+0x70/ 0x70 callback+ 0x15f/0x7e0 ap_work+ 0x2d0/0x2d0 0x4f1/0xeb0 ap_work+ 0x2d0/0x2d0 map_remove+ 0x1b1/0x1b1 swap_stop+ 0x2f0/0x2f0 map_remove+ 0x1b1/0x1b1 swap_stop+ 0x2f0/0x2f0 0xeb0/0xeb0 wake_function+ 0x2f/0x40 up_common+ 0xa1/0xc0 callbacks+ 0x52/0xa0 fun+0x117/ 0x1a0 thread_ fn+0x20e/ 0x2f0 0x30/0x30 0x30/0x30 create_ on_node+ 0xc0/0xc0 fork+0x1f/ 0x30
[ 426.302213] Hardware name: Cisco Systems Inc UCSC-C240-
[ 426.302215] Call Trace:
[ 426.302233] dump_stack+
[ 426.302241] ? dma_virt_
[ 426.302252] ? show_regs_
[ 426.302263] print_address_
[ 426.302269] kasan_report+
[ 426.302276] ? find_first_
[ 426.302288] __asan_
[ 426.302295] find_first_
[ 426.302306] has_busy_
[ 426.302314] intel_rdt_
[ 426.302321] ? clear_closid_
[ 426.302333] ? sysfs_remove_
[ 426.302339] ? clear_closid_
[ 426.302351] cpuhp_invoke_
[ 426.302360] ? cpuhp_kick_
[ 426.302372] ? __schedule+
[ 426.302377] ? cpuhp_kick_
[ 426.302385] ? firmware_
[ 426.302395] ? migrate_
[ 426.302402] ? firmware_
[ 426.302407] ? migrate_
[ 426.302414] ? schedule+0xd8/0x2a0
[ 426.302421] ? __schedule+
[ 426.302427] ? default_
[ 426.302439] ? __wake_
[ 426.302446] cpuhp_down_
[ 426.302453] cpuhp_thread_
[ 426.302459] ? cpu_up+0x20/0x20
[ 426.302468] smpboot_
[ 426.302474] ? sort_range+
[ 426.302482] kthread+0x1b7/0x1e0
[ 426.302488] ? sort_range+
[ 426.302493] ? kthread_
[ 426.302500] ret_from_
[ 426.307683] Allocated by task 56: trace+0x1b/ 0x20 0x43/0xd0 0xad/0xe0 0x105/0x230 online_ cpu+0x5a8/ 0x830 callback+ 0x15f/0x7e0 fun+0x8b/ 0x1a0 thread_ fn+0x20e/ 0x2f0 fork+0x1f/ 0x30
[ 426.312817] save_stack_
[ 426.312824] save_stack+
[ 426.312829] kasan_kmalloc+
[ 426.312834] __kmalloc+
[ 426.312840] intel_rdt_
[ 426.312846] cpuhp_invoke_
[ 426.312850] cpuhp_thread_
[ 426.312856] smpboot_
[ 426.312861] kthread+0x1b7/0x1e0
[ 426.312866] ret_from_
[ 426.317887] Freed by task 195: trace+0x1b/ 0x20 0x43/0xd0 free+0x72/ 0xc0 offline_ cpu+0x17d/ 0x510 callback+ 0x15f/0x7e0 callbacks+ 0x52/0xa0 fun+0x117/ 0x1a0 thread_ fn+0x20e/ 0x2f0 fork+0x1f/ 0x30
[ 426.322879] save_stack_
[ 426.322887] save_stack+
[ 426.322891] kasan_slab_
[ 426.322896] kfree+0x94/0x1a0
[ 426.322902] intel_rdt_
[ 426.322908] cpuhp_invoke_
[ 426.322912] cpuhp_down_
[ 426.322917] cpuhp_thread_
[ 426.322925] smpboot_
[ 426.322929] kthread+0x1b7/0x1e0
[ 426.322935] ret_from_
[ 426.327837] The buggy address belongs to the object at ffff883ff7c1e780
which belongs to the cache kmalloc-8 of size 8
8-byte region [ffff883ff7c1e780, ffff883ff7c1e788) df0780 count:1 mapcount:0 mapping: (null) index:0x0 0(slab)
[ 426.338289] The buggy address is located 0 bytes inside of
[ 426.348805] The buggy address belongs to the page:
[ 426.354223] page:ffffea00ff
[ 426.359838] flags: 0x57ffffc000010
[ 426.365373] raw: 0057ffffc0000100 0000000000000000 0000000000000000 0000000100aa00aa
[ 426.371135] raw: dead000000000100 dead000000000200 ffff8817f500fb80 0000000000000000
[ 426.377004] page dumped because: kasan: bad access detected
[ 426.388626] Memory state around the buggy address: ======= ======= ======= ======= ======= ======= ======= ======= ===
[ 426.394498] ffff883ff7c1e680: fc fc 00 fc fc fb fc fc 00 fc fc fb fc fc 00 fc
[ 426.400634] ffff883ff7c1e700: fc 00 fc fc fb fc fc 00 fc fc fb fc fc fb fc fc
[ 426.406721] >ffff883ff7c1e780: fb fc fc fb fc fc fb fc fc 00 fc fc fb fc fc fb
[ 426.412737] ^
[ 426.418698] ffff883ff7c1e800: fc fc fb fc fc fb fc fc fb fc fc fb fc fc fb fc
[ 426.424961] ffff883ff7c1e880: fc 00 fc fc fb fc fc fb fc fc fb fc fc fb fc fc
[ 426.431154] =======
[ 426.437413] Disabling lock debugging due to kernel taint
[ 426.472795] IRQ 8: no longer affine to CPU31
[ 426.472806] IRQ 9: no longer affine to CPU31
[ 426.472827] IRQ 40: no longer affine to CPU31
[ 426.473962] smpboot: CPU 31 is now offline
I ran it several more times without any obvious errors; however, I might have missed something. (The dmesg output is quite verbose and scrolls by quickly!)