On 2019-03-07, Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> wrote: >>> Sounds like another aurgment for the new printk design. >> >> Assuming the bad checksum messages are considered an emergency (for >> example, at least loglevel KERN_WARN), then the new printk design >> would print those messages synchronously to the slow serial line in >> the context of the driver as the driver is producing them. > > I wonder if we have several CPU doing the checksum verification. > New sync printk mechanism has a Big-Konsole-spin-Lock, all CPUs that > want to printk() should line up and wait, in whatever context they > currently are. > >> There wouldn't be a lock-up, but it would definitely slow down the >> driver. The situation of "messages being produced faster than the >> kernel can write them" would never exist because the printk() call >> will only return after the writing is completed. > > If the serial console is a really slow one and we have a CPU in atomic > context spinnig on prb_lock, while the prb_lock is always acquired by > other CPUs, then it may look like a lock-up scenario. 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). John Ogness
