Re: [Bug 42202] New: Caught 64-bit read from uninitialized memory in kmem_cache_alloc

[Christian Casteyde <casteyde.christian@free.fr>]

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>