lkml.org 
[lkml]   [2018]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On Wed, 10 Jan 2018 10:14:59 -0800
Tejun Heo <tj@kernel.org> wrote:

> On Wed, Jan 10, 2018 at 10:12:52AM -0800, Tejun Heo wrote:
> > Hello, Steven.
> >
> > So, everything else on your message, sure. You do what you have to
> > do, but I really don't understand the following part, and this has
> > been the main source of frustration in the whole discussion.
> >
> > On Wed, Jan 10, 2018 at 01:05:17PM -0500, Steven Rostedt wrote:
> > > You on the other hand are showing unrealistic scenarios, and crying
> > > that it's what you see in production, with no proof of it.
> >
> > I've explained the same scenario multiple times. Unless you're
> > assuming that I'm lying, it should be amply clear that the scenario is
> > unrealistic - we've been seeing them taking place repeatedly for quite
> > a while.
>
> Oops, I meant to write "not unrealistic". Anyways, if you think I'm
> lying, please let me know. I can ask others who have been seeing the
> issue to join the thread.

I don't believe you are lying. I believe you are interpreting one
problem as another. I don't see this is a printk bug, I see it as a
recursive OOM + net console bug. My patch is not trying to solve that,
and I don't believe it should be solved via printk.

I'm trying to solve the problem of printk spamming all CPUs causing a
single CPU to lock up. That is a real bug that has been hit in various
different scenarios, where there is no other underlying bug. This issue
is a printk problem, and my solution solves it for printk.

-- Steve

\
 
 \ /
  Last update: 2018-01-14 23:21    [W:0.134 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site