2019-11-21 08:14:45

by YT Chang

Subject: [PATCH 1/1] sched: panic, when call schedule with preemption disable

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 <[email protected]>
---
kernel/sched/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

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);
}
--
1.9.1

2019-11-21 12:32:31

by Peter Zijlstra

Subject: Re: [PATCH 1/1] sched: panic, when call schedule with preemption disable

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!?

2019-11-26 14:08:52

by YT Chang

Subject: Re: [PATCH 1/1] sched: panic, when call schedule with preemption disable

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.