Resending with Greg's correct email address.

On Fri, Jan 05, 2018 at 12:11:14PM +0000, Jamie Iles wrote:

Hi Greg,

When booting a 4.4.y stable-rc kernel with a fairly minimal config and CONFIG_KASAN=y and "nopti" on the kernel command line, or v4.4.109, I get a load of KASAN spews as below. A bisect takes me back to 85d3700c744a11 (x86/mm: If INVPCID is available, use it to flush global mappings), but I think the real fix is to also add 69e0210fd01ff15 (x86/kasan: Clear kasan_zero_page after TLB flush) onto your branch to address these false positives.

Thanks,

Jamie

[ 4.114576] BUG: KASAN: stack-out-of-bounds in __rmqueue.isra.66+0x14b/0xb50 at addr ffffea000467fd18 [ 4.115217] Read of size 4 by task swapper/0/0 [ 4.115529] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G B 4.4.109 #77 [ 4.116038] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014 [ 4.116651] 0000000000000000 ffffffff82807940 ffffffff8159a29d 0000000000000004 [ 4.117201] fffff940008cffa3 ffffffff828079c0 ffffffff812929e7 ffffffffffffffc3 [ 4.117758] 000000000467fd20 0000000000000082 ffffffff8121c87b 3634303030616566 [ 4.118318] Call Trace: [ 4.118503] [<ffffffff8159a29d>] dump_stack+0x86/0xc9 [ 4.118866] [<ffffffff812929e7>] kasan_report+0x327/0x4f0 [ 4.119252] [<ffffffff8121c87b>] ? __rmqueue.isra.66+0x14b/0xb50 [ 4.119685] [<ffffffff81291a33>] __asan_load4+0x23/0x70 [ 4.120063] [<ffffffff8121c87b>] __rmqueue.isra.66+0x14b/0xb50 [ 4.120472] [<ffffffff8121c730>] ? split_free_page+0xa0/0xa0 [ 4.120871] [<ffffffff81291b96>] ? __asan_store8+0x26/0x70 [ 4.121272] [<ffffffff8121d708>] get_page_from_freelist+0x488/0x11b0 [ 4.121722] [<ffffffff8121f4d2>] __alloc_pages_nodemask+0x2f2/0x5e0 [ 4.122165] [<ffffffff8121f1e0>] ? __alloc_pages_slowpath.constprop.73+0xc40/0xc40 [ 4.122698] [<ffffffff815bac5b>] ? _find_next_bit+0x3b/0xa0 [ 4.123101] [<ffffffff815bad0f>] ? find_first_bit+0x1f/0x70 [ 4.123499] [<ffffffff8128280d>] alloc_page_interleave+0x5d/0xc0 [ 4.123918] [<ffffffff812831e2>] alloc_pages_current+0x1b2/0x240 [ 4.124340] [<ffffffff8126de97>] __vmalloc_node_range+0x247/0x3d0 [ 4.124777] [<ffffffff82f1d3bb>] ? alloc_large_system_hash+0x168/0x250 [ 4.125248] [<ffffffff8126e06a>] __vmalloc+0x4a/0x50 [ 4.125613] [<ffffffff82f1d3bb>] ? alloc_large_system_hash+0x168/0x250 [ 4.126065] [<ffffffff82f1d3bb>] alloc_large_system_hash+0x168/0x250 [ 4.126461] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120 [ 4.126916] [<ffffffff82f25c6e>] vfs_caches_init+0xb7/0x108 [ 4.127307] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120 [ 4.127793] [<ffffffff82eed143>] start_kernel+0x4a3/0x524 [ 4.128194] [<ffffffff82eecca0>] ? thread_info_cache_init+0x6/0x6 [ 4.128625] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120 [ 4.129086] [<ffffffff82f73577>] ? memblock_reserve+0x4a/0x4f [ 4.129504] [<ffffffff82eec312>] x86_64_start_reservations+0x2a/0x2c [ 4.129948] [<ffffffff82eec456>] x86_64_start_kernel+0x142/0x151 [ 4.130373] Memory state around the buggy address: [ 4.130724] ffffea000467fc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4.131231] ffffea000467fc80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 [ 4.131737] >ffffea000467fd00: 00 00 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 [ 4.132233] ^ [ 4.132516] ffffea000467fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4.133026] ffffea000467fe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00