| Message ID | 1574323985-24193-1-git-send-email-yt.chang@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/1] sched: panic, when call schedule with preemption disable | expand |
On Thu, Nov 21, 2019 at 04:13:05PM +0800, YT Chang wrote: > When preemption is disable, call schedule() is incorrect behavior. > Suggest to panic directly rather than depend on panic_on_warn. Why!?
On Thu, 2019-11-21 at 13:30 +0100, Peter Zijlstra wrote: > On Thu, Nov 21, 2019 at 04:13:05PM +0800, YT Chang wrote: > > When preemption is disable, call schedule() is incorrect behavior. > > Suggest to panic directly rather than depend on panic_on_warn. > > Why!? 1. Panic directly will easily find the root cause. Call scheduling in atomic affects not only performance but also system stability. ex: Call scheduling in IRQ will result in IRQ enable after schedule() 2. A lot of warnings depend on panic_on_warn. It is not practical to set panic_on_warn=1.
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7880f4f..214e8d8 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3861,9 +3861,8 @@ static noinline void __schedule_bug(struct task_struct *prev) print_ip_sym(preempt_disable_ip); pr_cont("\n"); } - if (panic_on_warn) - panic("scheduling while atomic\n"); + panic("scheduling while atomic\n"); dump_stack(); add_taint(TAINT_WARN, LOCKDEP_STILL_OK); }
When preemption is disable, call schedule() is incorrect behavior. Suggest to panic directly rather than depend on panic_on_warn. Signed-off-by: YT Chang <yt.chang@mediatek.com> --- kernel/sched/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)