* Re: [Bug 42202] New: Caught 64-bit read from uninitialized memory in kmem_cache_alloc
2011-09-01 19:50 ` [Bug 42202] New: Caught 64-bit read from uninitialized memory in kmem_cache_alloc Andrew Morton
@ 2011-09-02 11:19 ` Christian Casteyde
0 siblings, 0 replies; 2+ messages in thread
From: Christian Casteyde @ 2011-09-02 11:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugzilla-daemon, linux-mm, Pekka Enberg, Vegard Nossum
I indeed use SLUB allocator.
I didn't managed to get the same call stack (no page fault) after rebooting,
but I'm wondering if it's a dup of
https://bugzilla.kernel.org/show_bug.cgi?id=36512
In this case this may not be a regression.
CC
Le jeudi 1 septembre 2011 21:50:45, Andrew Morton a écrit :
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 1 Sep 2011 17:15:00 GMT
>
> bugzilla-daemon@bugzilla.kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=42202
> >
> > Summary: Caught 64-bit read from uninitialized memory in
> >
> > kmem_cache_alloc
>
> I'm really struggling with this one.
>
> > Product: Memory Management
> > Version: 2.5
> >
> > Kernel Version: 3.1-rc4
> >
> > Platform: All
> >
> > OS/Version: Linux
> >
> > Tree: Mainline
> >
> > Status: NEW
> >
> > Severity: normal
> > Priority: P1
> >
> > Component: Page Allocator
> >
> > AssignedTo: akpm@linux-foundation.org
> > ReportedBy: casteyde.christian@free.fr
> > Regression: Yes
> >
> > Acer Aspire 7750G
> > Core i7 in 64bits mode
> > Slackware64 13.37
> > kmemcheck configured
> >
> > Since 3.1-rc4, I have the following warning at boot:
> >
> > udev[1745]: renamed network interface eth0 to eth1
> > udev[1699]: renamed network interface wlan0-eth0 to eth0
> > WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
> > (ffff8801c11865d0)
> > 000110000000adde000220000000addee06d18c10188ffff403d27c20188ffff
> >
> > f f f f f f f f f f f f f f f f u u u u u u u u u u u u u u u u
> >
> > ^
> >
> > Pid: 1700, comm: udevd Tainted: G W 3.1.0-rc4 #13 Acer Aspire
> > 7750G/JE70_HR
> > RIP: 0010:[<ffffffff8111aea6>] [<ffffffff8111aea6>]
> > kmem_cache_alloc+0x66/0x120
> > RSP: 0018:ffff8801c2103b38 EFLAGS: 00010246
> > RAX: 0000000000000000 RBX: ffff8801c23f6d10 RCX: 0000000000062720
> > RDX: 0000000000062718 RSI: 00000000001d43a0 RDI: 00000000000000d0
> > RBP: ffff8801c2103b68 R08: ffff8801c2109300 R09: 0000000000000001
> > R10: ffff8801c2109300 R11: 0000000000000000 R12: ffff8801c11865d0
> > R13: ffff8801c7414400 R14: 00000000000000d0 R15: ffffffff8110519f
> > FS: 00007fec4c108720(0000) GS:ffff8801c7800000(0000)
> > knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: ffff8801c604a0b0 CR3: 00000001c20f9000 CR4: 00000000000406f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
> >
> > [<ffffffff8110519f>] anon_vma_prepare+0x5f/0x190
> > [<ffffffff810fb0b6>] handle_pte_fault+0x576/0x790
> > [<ffffffff810fc5ff>] handle_mm_fault+0x11f/0x1c0
> > [<ffffffff810575d2>] do_page_fault+0x142/0x490
> > [<ffffffff817db57f>] page_fault+0x1f/0x30
> > [<ffffffff811858a0>] sysfs_read_file+0xf0/0x1a0
> > [<ffffffff8112166a>] vfs_read+0xaa/0x160
> > [<ffffffff81121768>] sys_read+0x48/0x90
> > [<ffffffff817dbabb>] system_call_fastpath+0x16/0x1b
> > [<ffffffffffffffff>] 0xffffffffffffffff
> >
> > Adding 2097148k swap on /dev/sda1. Priority:-1 extents:1 across:2097148k
> > EXT4-fs (sda2): re-mounted. Opts: (null)
> >
> > I do not know if it occurs with previous rc of 3.1, but I don't have it
> > with 3.0.
>
> It seems to be saying that the read occurred within kmem_cache_alloc().
>
> Or is the stack trace off-by-one, and the read is occurring in
> anon_vma_prepare()?
>
> Could you please take a look at the very nice
> Documentation/kmemcheck.txt and use the info in there to work out the
> exact file and line where the read is occurring? The "addr2line"
> operation.
>
> I'm having trojuble working out if your kernel is using slab or slub.
> This happens to me quite often. Pekka, perhaps we should add this info
> to the "Pid: 1700, comm: udevd Tainted: G W 3.1.0-rc4 #13 Acer Aspire"
> line. Or remove a few of our sl*b implementations...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 2+ messages in thread