Sergey Senozhatsky wrote: > On (12/28/17 15:48), Sergey Senozhatsky wrote: > [..] > > and I'm actually thinking about returning back the old vprintk_emit() > > behavior > > > > vprintk_emit() > > { > > + preempt_disable(); > > if (console_trylock()) > > console_unlock(); > > + preempt_enable(); > > } > > but am not going to. > it's outside of printk_kthread scope. and, besides, not every CPU which > is looping on console_unlock() came there via printk(). so by disabling > preemption in console_unlock() we cover more cases.
Just an idea: Do we really need to use a semaphore for console_sem? Is it possible to replace it with a spinlock? Then, I feel that we can write to consoles from non-process context (i.e. soft or hard IRQ context), with write only one log (or even one byte) at a time (i.e. write one log from one context, and defer all remaining logs by "somehow" scheduling for calling that context again). Since process context might fail to allow printk kernel thread to run for long period due to many threads waiting for run, I thought that interrupt context might fit better if we can "somehow" chain interrupt contexts.