Re: WARNING in tracing_func_proto

[Dmitry Vyukov]

On Wed, Jan 22, 2020 at 6:54 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
>
> On Tue, Jan 21, 2020 at 06:02:55PM -0500, Steven Rostedt wrote:
> > On Fri, 17 Jan 2020 23:47:11 -0800
> > syzbot <syzbot+0c147ca7bd4352547635@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:    428cd523 sfc/ethtool_common: Make some function to static
> > > git tree:       net-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=10483421e00000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=66d8660c57ff3c98
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=0c147ca7bd4352547635
> > > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+0c147ca7bd4352547635@xxxxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > ------------[ cut here ]------------
> > > Could not allocate percpu trace_printk buffer
> > > WARNING: CPU: 1 PID: 11733 at kernel/trace/trace.c:3112 alloc_percpu_trace_buffer kernel/trace/trace.c:3112 [inline]
> > > WARNING: CPU: 1 PID: 11733 at kernel/trace/trace.c:3112 trace_printk_init_buffers+0x5b/0x60 kernel/trace/trace.c:3126
> > > Kernel panic - not syncing: panic_on_warn set ...
> >
> > So it failed to allocate memory for the buffer (must be running low on
> > memory, or allocated a really big buffer?), and that triggered a
> > warning. As you have "panic_on_warn" set, the warning triggered the
> > panic.
> >
> > The only solution to this that I can see is to remove the WARN_ON and
> > replace it with a pr_warn() message. There's a lot of WARN_ON()s in the
> > kernel that need this conversion too, and I will postpone this change
> > to that effort.
> >
>
> I bet the syzbot folk have changed to lot of WARN_ON()s.  Maybe they
> just comment them out on their local tree?

FWIW this is invalid use of WARN macros:
https://elixir.bootlin.com/linux/v5.5-rc7/source/include/asm-generic/bug.h#L72
This should be replaced with pr_err (if really necessary, kernel does
not generally spew stacks on every ENOMEM/EINVAL).

There are no _lots_ such wrong uses of WARN in the kernel. There were
some, all get fixed over time, we are still discovering long tail, but
it's like one per months at most. Note: syzbot reports each and every
WARNING. If there were lots, you would notice :)

Sorting this out is critical for just any kernel testing. Otherwise no
testing system will be able to say if a test triggers something bad in
kernel or not.

FWIW there are no local trees for syzbot. It only tests public trees
as is. Doing otherwise would not work/scale as a process.