printk: Fix the qspinlock deadloop caused by zap_locks()

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/IBC1RM


CVE: NA

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

printk calls zap_locks() to bypass logbuf_lock during panic. If the
current system uses qspinlock, it may cause a deadloop in
queued_spin_lock_slowpath(). Consider the following locking sequence:

cpu1: (0, 0, 1)
cpu2: (0, 1, 1)
cpu3: (3, 1, 1)

If zap_locks() is called at this time, cpu2 may acquire the lock first,
and then cpu3 acquires the lock. When cpu3 releases the lock, it checks
if the tail is itself. Originally, it should be, but after zap_locks(),
the tail is modified to 0. At this point, cpu3 thinks there are other
contenders, it will first set the locked bit and then wait for the
contender to set its next pointer. However, in reality, there are no
other contenders, so cpu3 will hold the lock (locked bit is 1) and loop
here, causing other CPUs that want to acquire the lock to be stuck.

To fix this problem, the lock initialization in zap_locks() can be
degraded to clear locked_pending and retain the tail, avoiding
misjudgment.

Fixes: be926ed0 ("printk/panic: Avoid deadlock in printk()")
Signed-off-by: Li Huafei <lihuafei1@huawei.com>