On 10/30/2018 11:42 PM, Leon Romanovsky wrote:
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."
OK. Thanks for the note !!
