Re: Serial console is causing system lock-up

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (03/07/19 09:34), John Ogness wrote:
> >> When the console is constantly printing messages, I wouldn't say that
> >> looks like a lock-up scenario. It looks like the system is busy
> >> printing critical information to the console (which it is).
> >
> > What if we have N tasks/CPUs calling printk() simultaneously?
> 
> Then they take turns printing their messages to the console, spinning
> until they get their turn. This still is not and does not look like a
> lock-up. But I think you already know this, so I don't understand the
> reasoning behind asking the question. Maybe you could clarify what you
> are getting at.

Sorry John, the reasoning is that I'm trying to understand
why this does not look like soft or hard lock-up or RCU stall
scenario.

The CPU which spins on prb_lock() can have preemption disabled and,
additionally, can have local IRQs disabled, or be under RCU read
side lock. If consoles are busy, then there are CPUs which printk()
data and keep prb_lock contended; prb_lock() does not seem to be
fair. What am I missing? You probably talk about the case when all
printing CPUs are in preemptible contexts (assumingly this is what
is happening in dm-integrity case) so they can spin on prb_lock(),
that's OK. The case I'm talking about is - what if we have the same
situation, but then one of the CPUs printk()-s from !preemptible.
Does this make sense?

	-ss