在 2020/9/28 下午3:32, Peter Zijlstra 写道: > On Mon, Sep 28, 2020 at 12:11:30AM +0800, Chengming Zhou wrote: >> The WARN_ON/WARN_ON_ONCE with rq lock held in __schedule() should be >> deferred by marking the PRINTK_DEFERRED_CONTEXT_MASK, or will cause >> deadlock on rq lock in the printk path. > It also shouldn't happen in the first place, so who bloody cares.
Yes, but if our box deadlock just because a WARN_ON_ONCE, we have to reboot : ( So these WARN_ON_ONCE have BUG_ON effect ? Or we should change to use BUG_ON ? Thanks. >> Signed-off-by: Chengming Zhou <zhouchengm...@bytedance.com> >> Signed-off-by: Muchun Song <songmuc...@bytedance.com> >> --- >> kernel/sched/core.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 2d95dc3f4644..81d8bf614225 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -4444,6 +4444,7 @@ static void __sched notrace __schedule(bool preempt) >> */ >> rq_lock(rq, &rf); >> smp_mb__after_spinlock(); >> + printk_deferred_enter(); >> >> /* Promote REQ to ACT */ >> rq->clock_update_flags <<= 1; >> @@ -4530,6 +4531,7 @@ static void __sched notrace __schedule(bool preempt) >> rq_unlock_irq(rq, &rf); >> } >> >> + printk_deferred_exit(); >> balance_callback(rq); >> } > NAK printk_deferred is an abomination, kill that.
