From: David Rientjes <rientjes@google.com>
To: syzbot <syzbot+e38fe539fedfc127987e@syzkaller.appspotmail.com>,
Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
andreyknvl@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-usb@vger.kernel.org, mhocko@suse.com,
syzkaller-bugs@googlegroups.com, vbabka@suse.cz,
yang.shi@linux.alibaba.com, zhongjiang@huawei.com
Subject: Re: WARNING in __alloc_pages_nodemask
Date: Mon, 16 Sep 2019 13:00:11 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.1909161258150.118156@chino.kir.corp.google.com> (raw)
In-Reply-To: <00000000000025ae690592b00fbd@google.com>
On Mon, 16 Sep 2019, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=14b15371600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
> dashboard link: https://syzkaller.appspot.com/bug?extid=e38fe539fedfc127987e
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1093bed1600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1603cfc6600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e38fe539fedfc127987e@syzkaller.appspotmail.com
>
> WARNING: CPU: 0 PID: 1720 at mm/page_alloc.c:4696
> __alloc_pages_nodemask+0x36f/0x780 mm/page_alloc.c:4696
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 1720 Comm: syz-executor388 Not tainted 5.3.0-rc7+ #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
> 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> panic+0x2a3/0x6da kernel/panic.c:219
> __warn.cold+0x20/0x4a kernel/panic.c:576
> report_bug+0x262/0x2a0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:179 [inline]
> fixup_bug arch/x86/kernel/traps.c:174 [inline]
> do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272
> do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291
> invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
> RIP: 0010:__alloc_pages_nodemask+0x36f/0x780 mm/page_alloc.c:4696
> Code: fe ff ff 65 48 8b 04 25 00 ef 01 00 48 05 60 10 00 00 41 be 01 00 00 00
> 48 89 44 24 58 e9 ee fd ff ff 81 e5 00 20 00 00 75 02 <0f> 0b 45 31 f6 e9 6b
> ff ff ff 8b 44 24 68 89 04 24 65 8b 2d e9 7e
> RSP: 0018:ffff8881d320f9d8 EFLAGS: 00010046
> RAX: 0000000000000000 RBX: 1ffff1103a641f3f RCX: 0000000000000000
> RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000040a20
> RBP: 0000000000000000 R08: ffff8881d3bcc800 R09: ffffed103a541d19
> R10: ffffed103a541d18 R11: ffff8881d2a0e8c7 R12: 0000000000000012
> R13: 0000000000000012 R14: 0000000000000000 R15: ffff8881d2a0e8c0
> alloc_pages_current+0xff/0x200 mm/mempolicy.c:2153
> alloc_pages include/linux/gfp.h:509 [inline]
> kmalloc_order+0x1a/0x60 mm/slab_common.c:1257
> kmalloc_order_trace+0x18/0x110 mm/slab_common.c:1269
> __usbhid_submit_report drivers/hid/usbhid/hid-core.c:588 [inline]
> usbhid_submit_report+0x5b5/0xde0 drivers/hid/usbhid/hid-core.c:638
> usbhid_request+0x3c/0x70 drivers/hid/usbhid/hid-core.c:1252
> hid_hw_request include/linux/hid.h:1053 [inline]
> hiddev_ioctl+0x526/0x1550 drivers/hid/usbhid/hiddev.c:735
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:509 [inline]
> do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
> ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl fs/ioctl.c:718 [inline]
> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
> do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
Adding Jiri and Benjamin. The hid report length is simply too large for
the page allocator to allocate: this is triggering because the resulting
allocation order is > MAX_ORDER-1. Any way to make this allocate less
physically contiguous memory?
next prev parent reply other threads:[~2019-09-16 20:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 18:49 syzbot
2019-09-16 20:00 ` David Rientjes [this message]
2019-09-16 20:57 ` Matthew Wilcox
2019-09-19 18:29 ` Andrey Konovalov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1909161258150.118156@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-usb@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=syzbot+e38fe539fedfc127987e@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vbabka@suse.cz \
--cc=yang.shi@linux.alibaba.com \
--cc=zhongjiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox