printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

[Petr Mladek]

On Sat 2017-07-08 22:30:47, Tetsuo Handa wrote:
> What I want to mention here is that messages which were sent to printk()
> were not printed to not only /dev/tty0 but also /dev/ttyS0 (I'm passing
> "console=ttyS0,115200n8 console=tty0" to kernel command line.) I don't care
> if output to /dev/tty0 is delayed, but I expect that output to /dev/ttyS0
> is not delayed, for I'm anayzing things using printk() output sent to serial
> console (serial.log in my VMware configuration). Hitting this problem when we
> cannot allocate memory results in failing to save printk() output. Oops, it
> is sad.

Would it be acceptable to remove "console=tty0" parameter and push
the messages only to the serial console?

Also there is the patchset from Peter Zijlstra that allows to
use early console all the time, see
https://lkml.kernel.org/r/20161018170830.405990950@infradead.org


The current code flushes each line to all enabled consoles one
by one. If there is a deadlock in one console, everything
gets blocked.

We are trying to make printk() more robust. But it is much more
complicated than we anticipated. Many changes open another can
of worms. It seems to be a job for years.


> Hmm... should we consider addressing console_sem problem before
> introducing printing kernel thread and offloading to that kernel thread?

As Sergey said, the console rework seems to be much bigger task
than introducing the kthread.

Also if we would want to handle each console separately (as a
fallback) it would be helpful to have separate kthread for each
enabled console or for the less reliable consoles at least.

Best Regards,
Petr