On Tue, Oct 30, 2018 at 12:38:02PM -0700, Santosh Shilimkar wrote:

On 10/30/2018 12:28 PM, syzbot wrote:

quoted

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@syzkaller.appspotmail.com

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