euler inclusion
category: bugfix
bugzilla: 9509
CVE: NA
------------------------------------------------

Syzkaller hit 'possible deadlock in console_unlock' for several times.
Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&port->lock)->rlock);
                               lock(&port_lock_key);
                               lock(&(&port->lock)->rlock);
  lock(console_owner);

The problem is that call_console_driver->console_driver also can do
this thing

   uart_port->lock
    tty_wakeup
     tty_port->lock

So we can have the following:

tty_write
 tty_port->lock
  printk
   call_console_driver
    console_driver
     uart_port->lock
      tty_wakeup
       tty_port->lock      << deadlock

To solve this problem,  switch to printk_safe mode around that kmalloc(),
this will redirect all printk()-s from kmalloc() to a special per-CPU
buffer, which will be flushed later from a safe context (irq work).
Signed-off-by: NHongbo Yao <yaohongbo@huawei.com>
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>