disable scheduler warnings during oopses.
RFC 1/1 disable scheduler warnings during oopses.
The panic-on-framebuffer code seems to cause a schedule
to occur during an oops. This causes a bunch of extra
spew as can be seen in https://bugzilla.redhat.com/attachment.cgi?id=549230
Would this (untested) patch be sufficient here, or does the drm code need rearchitecting to not perform allocations during panic ?
kernel/sched.c +3 -0
@@ -4321,6 +4321,9 @@ static noinline void __schedule_bug(struct task_struct *prev) {struct pt_regs *regs =get_irq_regs (); +if (oops_in_progress) +return ; +printk (KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n" , prev->comm, prev->pid,preempt_count ());
Quoted 14 lines · Dave Jones
The panic-on-framebuffer code seems to cause a schedule
to occur during an oops. This causes a bunch of extra
spew as can be seen in https://bugzilla.redhat.com/attachment.cgi?id=549230Would this (untested) patch be sufficient here, or does the drm code need rearchitecting to not perform allocations during panic ?
Signed-off-by Dave Jones <[email protected]>kernel/sched.c +0
-0
kernel/sched.c static noinline void __schedule_bug(struct task_struct *prev) · line 4329
Quoted 9 lines
kernel/sched.c +3
-0@@ -4321,6 +4321,9 @@ static noinline void __schedule_bug(struct task_struct *prev) {struct pt_regs *regs =get_irq_regs (); +if (oops_in_progress) +return ; +printk (KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n" , prev->comm, prev->pid,preempt_count ());
Doing that makes sense - if an oops in going on we don't want to produce recursive messages. Note that scheduler code has been moved to kernel/sched/, so i've changed the patch accordingly.
Note that despite that, the DRM code *definitely* needs to be fixed to not allocate and schedule while printing on the framebuffer in KMS mode ...
Thanks,
Ingo
Quoted 19 lines · Ingo Molnar
Quoted 17 lines · Dave Jones
The panic-on-framebuffer code seems to cause a schedule
to occur during an oops. This causes a bunch of extra
spew as can be seen in https://bugzilla.redhat.com/attachment.cgi?id=549230Would this (untested) patch be sufficient here, or does the drm code need rearchitecting to not perform allocations during panic ?
Signed-off-by Dave Jones <[email protected]>kernel/sched.c +0
-0@@ -4321,6 +4321,9 @@ static noinline void __schedule_bug(struct task_struct *prev) {struct pt_regs *regs =get_irq_regs ();
Quoted 10 lines
kernel/sched.c static noinline void __schedule_bug(struct task_struct *prev) · line 4329
Quoted 6 lines
kernel/sched.c +3
-0+if (oops_in_progress) +return ; +printk (KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n" , prev->comm, prev->pid,preempt_count ());Doing that makes sense - if an oops in going on we don't want to produce recursive messages. Note that scheduler code has been moved to
kernel/sched/, so i've changed the patch accordingly.
Urgh I would actually argue against merging this. What the KSM console does is horridly wrong, and simply papering over it doesn't help its cause. Its up there with USB-Serial console on wrongness.
Quoted 3 lines
Note that despite that, the DRM code *definitely* needs to be fixed to not allocate and schedule while printing on the framebuffer in KMS mode ...
For sure, its plain insane and completely unreliable.
Quoted 32 lines · Peter Zijlstra
Quoted 19 lines · Ingo Molnar
Quoted 17 lines · Dave Jones
The panic-on-framebuffer code seems to cause a schedule
to occur during an oops. This causes a bunch of extra
spew as can be seen in https://bugzilla.redhat.com/attachment.cgi?id=549230Would this (untested) patch be sufficient here, or does the drm code need rearchitecting to not perform allocations during panic ?
Signed-off-by Dave Jones <[email protected]>kernel/sched.c +0
-0@@ -4321,6 +4321,9 @@ static noinline void __schedule_bug(struct task_struct *prev) {struct pt_regs *regs =get_irq_regs ();Quoted 11 lines
kernel/sched.c static noinline void __schedule_bug(struct task_struct *prev) · line 4329
Quoted 6 lines
kernel/sched.c +3
-0+if (oops_in_progress) +return ; +printk (KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n" , prev->comm, prev->pid,preempt_count ());Doing that makes sense - if an oops in going on we don't want to produce recursive messages. Note that scheduler code has been moved to
kernel/sched/, so i've changed the patch accordingly.
Quoted 4 lines
Urgh I would actually argue against merging this. What the KSM console does is horridly wrong, and simply papering over it doesn't help its cause. Its up there with USB-Serial console on wrongness.
Well, i agree in principle, but not escallating an already bad scenario would be a basic robustness rule. We do skip certain things on oops_in_progress already.
Linus, Andrew, what would be your preference?
Thanks,
Ingo
[tip:sched/core] sched: Disable scheduler warnings during oopses
In reply to Dave JonesCommit-ID: 664dfa65e84429d0b68694483e1de7365c7c56fb Gitweb: http://git.kernel.org/tip/664dfa65e84429d0b68694483e1de7365c7c56fb Author: Dave Jones <[email protected]> AuthorDate: Thu, 22 Dec 2011 16:39:30 -0500 Committer: Ingo Molnar <[email protected]> CommitDate: Fri, 23 Dec 2011 11:20:50 +0100
sched: Disable scheduler warnings during oopses
The panic-on-framebuffer code seems to cause a schedule to occur during an oops. This causes a bunch of extra spew as can be seen in:
https://bugzilla.redhat.com/attachment.cgi?id=549230
Don't do scheduler debug checks when we are oopsing already.
--- kernel/sched/core.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
kernel/sched/core.c +3 -0
@@ -3077,6 +3077,9 @@ static noinline void __schedule_bug(struct task_struct *prev) {struct pt_regs *regs =get_irq_regs (); +if (oops_in_progress) +return ; +printk (KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n" , prev->comm, prev->pid,preempt_count ());