Prev: ipc: use shifts to extract seq/idx
Next: [PATCH v2 3/3] omap: cpu: Implement callbacks for cpu frequency tracking in cpuacct
From: Andrew Morton on 20 May 2010 14:40
On Thu, 20 May 2010 14:17:40 -0400
> If a process is exiting with a non-zero preempt_count, it's in fact almost
> certainly going to fail to do so because it is exiting due to a BUG or OOPS
> while it held a lock, at which point it will never actually exit. So change
> the message to say it attempted to do so, rather than implying it succeeded.
> Problem spotted when a process BUG'ed, the kernel reported the 'exited' status,
> and then proceeded to BUG twice more dealing with the now-zombied process:
> > [ 35.357018] note: keymap exited with preempt_count 1
> > [ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
> Yes, one line is 83 characters. It's still more readable than a split printk.
> Signed-off-by: Valdis Kletnieks <valdis.kletnieks(a)vt.edu>
> --- linux-2.6.34-mmotm0519/kernel/exit.c.dist 2010-05-20 10:59:11.646870592 -0400
> +++ linux-2.6.34-mmotm0519/kernel/exit.c 2010-05-20 14:05:16.068800223 -0400
> @@ -936,7 +936,7 @@ NORET_TYPE void do_exit(long code)
> if (unlikely(in_atomic()))
> - printk(KERN_INFO "note: %s[%d] exited with preempt_count %d\n",
> + printk(KERN_INFO "note: %s[%d] tried to exit with preempt_count %d\n",
> current->comm, task_pid_nr(current),
a) this message is kinda like __schedule_bug(), only
__schedule_bug() does more stuff. Perhaps some sharing is in order.
b) do_exit() eventually calls schedule() anyway, so if we have a bad
preempt_count() here, schedule() should end up calling
__schedule_bug(), so we don't need this message in do_exit().
ah-hah, __schedule_bug() doesn't get called on the exit() path due to
task->state==TASK_DEAD. But we can surely change that.
schedule_debug() needs fixing anyway - what's it doing assuming that
c) it's pretty pointless printing anything at all if this task has
oopsed. This info is never interesting and will just cause the
useful info to scroll into oblivion.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/