On Tue, Oct 30, 2018 at 12:38:02PM -0700, Santosh Shilimkar wrote: > On 10/30/2018 12:28 PM, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: 6201f31a39f8 Add linux-next specific files for 20181030 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=1397d06d400000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=2a22859d870756c1 > > dashboard link: > > https://syzkaller.appspot.com/bug?extid=26de17458aeda9d305d8 > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10bb52eb400000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=118bdfc5400000 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+26de17458aeda9d305d8@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > WARNING: CPU: 0 PID: 19789 at net/rds/message.c:316 > > rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316 > > Kernel panic - not syncing: panic_on_warn set ... > Looks like this kernel build has panic on warn enabled which > triggers panic for " WARN_ON(!nr_pages)" case. Will look into > it. Thanks !! Please don't forget to remove user triggered WARN_ON. https://lwn.net/Articles/769365/ "Greg Kroah-Hartman raised the problem of core kernel API code that will use WARN_ON_ONCE() to complain about bad usage; that will not generate the desired result if WARN_ON_ONCE() is configured to crash the machine. He was told that the code should just call pr_warn() instead, and that the called function should return an error in such situations. It was generally agreed that any WARN_ON() or WARN_ON_ONCE() calls that can be triggered from user space need to be fixed." Thanks > > Regards, > Santosh
Attachment:
signature.asc
Description: PGP signature
