printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

[Daniel Vetter]

On Mon, Jul 10, 2017 at 2:59 PM, Petr Mladek <pmladek at suse.com> wrote:
> 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.

Since the console-loggin-in-kthread comes up routinely, and equally
often people say "but I dont want to make my serial console delayed":
Should we make kthread-based printk a per-console opt-in? fbcon and
other horror shows with deep nesting of entire subsystems and their
locking hierarchy would do that. Truly simple console drivers like
serial or maybe logging to some firmware/platform service for recovery
after rebooting would not.

Of course we'd also need one kthread per console, and we'd need to
have at least some per-console locking (plus an overall console lock
on top for both registering/unregistering consoles and all the legacy
users like fbdev that need much more work to untangle). We could even
restrict the per-console locking (i.e. those which can go ahead while
someone else is holding the main or other console_locks) just for
those console drivers which do not use a kthread, to cut down the
audit burden to something manageable.

Just my 2 cents, thrown in from the sideline.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch