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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
