lkml.org 
[lkml]   [2009]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [kmemcheck] visual_init(): Caught 32-bit read from unallocated memory (bf820028)
From
2009/10/4 Ingo Molnar <mingo@elte.hu>:
>
> hi,
>
> got this kmemcheck warning in -tip testing:
>
> [    0.000000] WARNING: kmemcheck: Caught 32-bit read from unallocated memory (bf820028)
> [    0.000000] 0000000000000000000000000000000000000000000000000000000000000000
> [    0.000000]  a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
> [    0.000000]                  ^
> [    0.000000]
> [    0.000000] Pid: 0, comm: swapper Not tainted (2.6.32-rc2-tip-01349-g1ade8d6-dirty #218) P4DC6
> [    0.000000] EIP: 0060:[<812d78c0>] EFLAGS: 00010286 CPU: 0
> [    0.000000] EIP is at visual_init+0x10/0x130
> [    0.000000] EAX: bf820000 EBX: bf820000 ECX: 00000001 EDX: 00000000
> [    0.000000] ESI: 00000200 EDI: 00000000 EBP: 81abdf7c ESP: 81c1a94c
> [    0.000000]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [    0.000000] CR0: 8005003b CR2: bf820028 CR3: 01c10000 CR4: 000006d0
> [    0.000000] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [    0.000000] DR6: ffff4ff0 DR7: 00000400
> [    0.000000]  [<81b99d82>] con_init+0xf2/0x2b0
> [    0.000000]  [<81b99239>] console_init+0x19/0x30
> [    0.000000]  [<81b7492d>] start_kernel+0x1cd/0x340
> [    0.000000]  [<81b74091>] i386_start_kernel+0x61/0x90
> [    0.000000]  [<ffffffff>] 0xffffffff
> [    0.000000]   ok  |  ok  |  ok  |
>
> seems new at first glance. Config attached.
>
>        Ingo
>

BTW, unallocated means "the page was allocated for use by SL*B, but
the object has not been handed out to anyone yet".

The memory access that triggers this warning is the first line of the function:

00003350 <visual_init>:
...
3366: 8b 47 28 mov 0x28(%edi),%eax

$ addr2line -e drivers/char/vt.o -i 3366
drivers/char/vt.c:721

718 static void visual_init(struct vc_data *vc, int num, int init)
719 {
720 /* ++Geert: vc->vc_sw->con_init determines console size */
721 if (vc->vc_sw)

So apparently the "vc" we got is invalid. The caller:

2833 static int __init con_init(void)
2834 {
...
2870 for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
2871 vc_cons[currcons].d = vc = kzalloc(sizeof(struct
vc_data), GFP_NOWAIT);
2872 INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
2873 visual_init(vc, currcons, 1);
...
2897 }
2898 console_initcall(con_init);

Not entirely sure about the rest of the story... It would seem that we
are missing an if (!vc), but that doesn't explain how the pointer got
to be 0xbf820000. What sort of address is that, anyway, isn't that a
userspace pointer? Ah, you have CONFIG_VMSPLIT_2G=y. Can we see the
kernel virtual memory map from the dmesg?

I can't really see how this is possible, which means that kmemcheck is
probably at fault.


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-10-04 21:33    [W:0.067 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site