panic/printk: fix zap_lock

hulk inclusion
category: bugfix
bugzilla: 34546, https://gitee.com/openeuler/kernel/issues/I4JKT1


CVE: NA

----------------------------------------

There are two problems with the implementation and use of
zap_lock().

Firstly, This console_sem does not require reinit in zap_lock(),
this is because:

1). printk() itself does try_lock() and skips console handling
when the semaphore is not available.

2). panic() tries to push the messages later in console_flush_on_panic().
It ignores the semaphore. Also most console drivers ignore their
internal locks because oops_in_progress is set by bust_spinlocks().

Secondly, The situation is more complicated when NMI is not used.

1). Non-stopped CPUs are in unknown state, most likely in a busy loop.
Nobody knows whether printk() is repeatedly called in the loop.
When it was called, re-initializing any lock would cause double
unlock and deadlock.

2). It would be possible to add some more hacks. One problem is that
there are two groups of users. One prefer to risk a deadlock and
have a chance to see the messages. Others prefer to always
reach emergency_restart() and reboot the machine.

Fixes: d0dfaa87c2aa ("printk/panic: Avoid deadlock in printk()")
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>