lkml.org 
[lkml]   [2022]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [tip:x86/mm] [x86/mm] 1248fb6a82: Kernel_panic-not_syncing:kasan_populate_pmd:Failed_to_allocate_page
From
Hi Peter,

On 10/25/2022 6:33 PM, Peter Zijlstra wrote:
> On Tue, Oct 25, 2022 at 12:54:40PM +0800, kernel test robot wrote:
>> Hi Peter,
>>
>> We noticed that below commit changed the value of
>> CPU_ENTRY_AREA_MAP_SIZE. Seems KASAN uses this value to allocate memory,
>> and failed during initialization after this change, so we send this
>> mail and Cc KASAN folks. Please kindly check below report for more
>> details. Thanks.
>>
>>
>> Greeting,
>>
>> FYI, we noticed Kernel_panic-not_syncing:kasan_populate_pmd:Failed_to_allocate_page due to commit (built with gcc-11):
>>
>> commit: 1248fb6a8201ddac1c86a202f05a0a1765efbfce ("x86/mm: Randomize per-cpu entry area")
>> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git x86/mm
>>
>> in testcase: boot
>>
>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>>
>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>>
>>
>> [ 7.114808][ T0] Kernel panic - not syncing: kasan_populate_pmd+0x142/0x1d2: Failed to allocate page, nid=0 from=1000000
>> [ 7.119742][ T0] CPU: 0 PID: 0 Comm: swapper Not tainted 6.1.0-rc1-00001-g1248fb6a8201 #1
>> [ 7.122122][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
>> [ 7.124976][ T0] Call Trace:
>> [ 7.125849][ T0] <TASK>
>> [ 7.126642][ T0] ? dump_stack_lvl+0x45/0x5d
>> [ 7.127908][ T0] ? panic+0x21e/0x46a
>> [ 7.129009][ T0] ? panic_print_sys_info+0x77/0x77
>> [ 7.130618][ T0] ? memblock_alloc_try_nid_raw+0x106/0x106
>> [ 7.132224][ T0] ? memblock_alloc_try_nid+0xd9/0x118
>> [ 7.133717][ T0] ? memblock_alloc_try_nid_raw+0x106/0x106
>> [ 7.135252][ T0] ? kasan_populate_pmd+0x142/0x1d2
>> [ 7.136655][ T0] ? early_alloc+0x95/0x9d
>> [ 7.137738][ T0] ? kasan_populate_pmd+0x142/0x1d2
>> [ 7.138936][ T0] ? kasan_populate_pud+0x182/0x19f
>> [ 7.140335][ T0] ? kasan_populate_shadow+0x1e0/0x233
>> [ 7.141759][ T0] ? kasan_init+0x3be/0x57f
>> [ 7.142942][ T0] ? setup_arch+0x101d/0x11f0
>> [ 7.144229][ T0] ? start_kernel+0x6f/0x3d0
>> [ 7.145449][ T0] ? secondary_startup_64_no_verify+0xe0/0xeb
>> [ 7.147051][ T0] </TASK>
>> [ 7.147868][ T0] ---[ end Kernel panic - not syncing: kasan_populate_pmd+0x142/0x1d2: Failed to allocate page, nid=0 from=1000000 ]---
>
> Ufff, no idea about what KASAN wants here; Andrey, you have clue?
>
> Are you trying to allocate backing space for .5T of vspace and failing
> that because the kvm thing doesn't have enough memory?
Here is what I got when I checked whether this report is valid or not:

KASAN create shadow for cpu entry area:
shadow_cpu_entry_begin = (void *)CPU_ENTRY_AREA_BASE;
shadow_cpu_entry_begin = kasan_mem_to_shadow(shadow_cpu_entry_begin);
shadow_cpu_entry_begin = (void *)round_down(
(unsigned long)shadow_cpu_entry_begin, PAGE_SIZE);

shadow_cpu_entry_end = (void *)(CPU_ENTRY_AREA_BASE +
CPU_ENTRY_AREA_MAP_SIZE);
^^^^^^^^^^^^^^^^^^^^^^^
shadow_cpu_entry_end = kasan_mem_to_shadow(shadow_cpu_entry_end);
shadow_cpu_entry_end = (void *)round_up(
(unsigned long)shadow_cpu_entry_end, PAGE_SIZE);

.....
kasan_populate_shadow((unsigned long)shadow_cpu_entry_begin,
(unsigned long)shadow_cpu_entry_end, 0)

Before the patch, the CPU_ENTRY_AREA_MAP_SIZE is:
(CPU_ENTRY_AREA_PER_CPU + CPU_ENTRY_AREA_ARRAY_SIZE - CPU_ENTRY_AREA_BASE)

After the patch, it's same for 32bit. But for 64bit, it's: P4D_SIZE.
And trigger kasan_populate_shadow() applied to a very large range.

Hope this info could help somehow. Thanks.

Regards
Yin, Fengwei

>

\
 
 \ /
  Last update: 2022-10-25 16:19    [W:0.313 / U:19.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site