Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Tejun Heo <tj@kernel.org>]

Hello, Steven.

On Fri, Jan 19, 2018 at 01:20:52PM -0500, Steven Rostedt wrote:
> I was thinking about this a bit more, and instead of offloading a
> recursive printk, perhaps its best to simply throttle it. Because the
> problem may not go away if a printk thread takes over, because the bug
> is really the printk infrastructure filling the printk buffer keeping
> printk from ever stopping.
> 
> This patch detects that printk is causing itself to print more and
> throttles it after 3 messages have printed due to recursion. Could you
> see if this helps your test cases?

Sure, if this is the approach we're gonna take, I can try it with the
silly test code and also try to reproduce the original problem and see
whether this helps.

I'm a bit worried tho because this essentially seems like "detect
recursion, ignore messages" approach.  netcons can have a very large
surface for bugs.  Suppressing those messages would make them
difficult to debug.  For example, all our machines have both serial
console (thus the slowness) and netconsole hooked up and netcons code
has had its fair share of issues.  This would likely make tracking
down those problems more challenging.

Can we discuss pros and cons of this approach against offloading
before committing to this?

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>