* Re: [Bug 42202] New: Caught 64-bit read from uninitialized memory in kmem_cache_alloc
[not found] <bug-42202-27@https.bugzilla.kernel.org/>
@ 2011-09-01 19:50 ` Andrew Morton
2011-09-02 11:19 ` Christian Casteyde
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Morton @ 2011-09-01 19:50 UTC (permalink / raw)
To: casteyde.christian; +Cc: bugzilla-daemon, linux-mm, Pekka Enberg, Vegard Nossum
(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
* 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
end of thread, other threads:[~2011-09-02 11:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-42202-27@https.bugzilla.kernel.org/>
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox