lkml.org 
[lkml]   [2018]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: WARNING in __alloc_pages_slowpath
From
Date
On 01/04/2018 06:10 AM, Vlastimil Babka wrote:
> On 01/04/2018 02:57 PM, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 71ee203389f7cb1c1927eab22b95baa01405791c
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+76e7efc4748495855a4d@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1514727386.271:7): avc: denied { map } for
>> pid=3485 comm="syzkaller426814" path="/root/syzkaller426814263" dev="sda1"
>> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
>> WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926
>> __alloc_pages_slowpath+0x1ffc/0x2d00 mm/page_alloc.c:3936
>
> This is a warning about order >= MAX_ORDER.
>
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 1 PID: 3485 Comm: syzkaller426814 Not tainted 4.15.0-rc5+ #244
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x194/0x257 lib/dump_stack.c:53
>> panic+0x1e4/0x41c kernel/panic.c:183
>> __warn+0x1dc/0x200 kernel/panic.c:547
>> report_bug+0x211/0x2d0 lib/bug.c:184
>> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>> fixup_bug arch/x86/kernel/traps.c:247 [inline]
>> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>> invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
>> RIP: 0010:__alloc_pages_slowpath+0x1ffc/0x2d00 mm/page_alloc.c:3936
>> RSP: 0018:ffff8801c011f418 EFLAGS: 00010246
>> RAX: ffffed0038023ea4 RBX: 1ffff10038023ea4 RCX: 0000000000000000
>> RDX: ffff8801c011fa70 RSI: 0000000000000033 RDI: 0000000000000000
>> RBP: ffff8801c011f908 R08: 0000000000000000 R09: fffffffffff80f8a
>> R10: 0000000000000033 R11: 0000000000000033 R12: 0000000000000000
>> R13: ffff8801c011fad0 R14: 00000000014280c2 R15: ffff8801c011fa70
>> __alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
>> alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
>> alloc_pages include/linux/gfp.h:492 [inline]
>> ion_system_contig_heap_allocate+0x40/0x2c0
>> drivers/staging/android/ion/ion_system_heap.c:374
>
> And the allocation came from here. It should use smaller order, or
> __NOWARN if this is some kind of opportunistic attempt. Maybe the order
> comes all the way from userspace ioctl?
>

Yes, the order is coming directly from userspace as the size
requested for an Ion allocation. I think we do need to at least
pass __NOWARN for the system contig heap case.

Thanks,
Laura

\
 
 \ /
  Last update: 2018-01-04 19:51    [W:0.038 / U:1.988 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site