[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180626042208.GA31439@jagdpanzerIV>
Date: Tue, 26 Jun 2018 13:22:08 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
syzbot <syzbot+d29d18215e477cfbfbdd@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, pmladek@...e.com,
sergey.senozhatsky@...il.com, syzkaller-bugs@...glegroups.com,
Samuel Ortiz <sameo@...ux.intel.com>,
"David S. Miller" <davem@...emloft.net>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: INFO: rcu detected stall in vprintk_emit
On (06/25/18 22:59), Steven Rostedt wrote:
> > Or ratelimited error reporting and cond_resched()
> > [that would be option B]:
>
> I don't think this is a printk() issue per se, so I think Option B is
> the only option. You should not get stuck in an infinite loop if we run
> short on memory. Perhaps we could have an Option C which would exit
> this loop gracefully with some kind of error. But I haven't looked at
> the surrounding code to be sure if that is possible.
Agree. I like Option B - an endless loop is the root cause, at the same
time filling up logbuf with useless data is useless. Can't tell if Option C
is feasible, up to networking people.
-ss
Powered by blists - more mailing lists