Re: [RFC/PATCH] x86: Use KERN_DEFAULT log-level in __show_regs()

From: Pekka Enberg
Date: Tue Dec 29 2009 - 02:08:45 EST


Joe Perches kirjoitti:
On Mon, 2009-12-28 at 10:26 +0200, Pekka Enberg wrote:
From: Pekka Enberg <penberg@xxxxxxxxxxxxxx>

Andrew Morton reported a strange looking kmemcheck warning:

WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88004fba6c20)
0000000000000000310000000000000000000000000000002413000000c9ffff
u u u u u u u u u u u u u u u u i i i i i i i i u u u u u u u u

[<ffffffff810af3aa>] kmemleak_scan+0x25a/0x540
[<ffffffff810afbcb>] kmemleak_scan_thread+0x5b/0xe0
[<ffffffff8104d0fe>] kthread+0x9e/0xb0
[<ffffffff81003074>] kernel_thread_helper+0x4/0x10
[<ffffffffffffffff>] 0xffffffffffffffff

The above printout is missing register dump completely. The problem here is
that the output comes from syslog which doesn't show KERN_INFO log-level
messages. We didn't see this before because both of us were testing on 32-bit
kernels which use the _default_ log-level.

Fix that up by explicitly using KERN_DEFAULT log-level for __show_regs()
printks.

Cc: Vegard Nossum <vegard.nossum@xxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Pekka Enberg <penberg@xxxxxxxxxxxxxx>
---
arch/x86/kernel/process.c | 4 ++--
arch/x86/kernel/process_32.c | 14 +++++++-------
arch/x86/kernel/process_64.c | 24 ++++++++++++------------
3 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 98c2cde..c6ee241 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -103,8 +103,8 @@ void show_regs_common(void)
if (!product)
product = "";
- printk("\n");
- printk(KERN_INFO "Pid: %d, comm: %.20s %s %s %.*s %s/%s\n",
+ printk(KERN_CONT "\n");
+ printk(KERN_DEFAULT "Pid: %d, comm: %.20s %s %s %.*s %s/%s\n",

What is the reason to convert KERN_INFO to KERN_DEFAULT here?

To be consistent with rest of __show_regs() log-levels.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/