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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx > > ReportedBy: casteyde.christian@xxxxxxx > > 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@xxxxxxxxx. 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