Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751566Ab3IHGLv (ORCPT ); Sun, 8 Sep 2013 02:11:51 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:52782 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987Ab3IHGLt (ORCPT ); Sun, 8 Sep 2013 02:11:49 -0400 Message-ID: <522C151F.8020601@openvz.org> Date: Sun, 08 Sep 2013 10:11:43 +0400 From: Konstantin Khlebnikov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130823 Firefox/10.0.11esrpre Iceape/2.7.12 MIME-Version: 1.0 To: Sasha Levin CC: Andrew Morton , "linux-mm@kvack.org" , LKML , walken@google.com, riel@redhat.com, hughd@google.com, trinity@vger.kernel.org Subject: Re: mm: gpf in find_vma References: <522B9B5D.4010207@oracle.com> In-Reply-To: <522B9B5D.4010207@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4077 Lines: 81 Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest, running latest -next kernel, I've > stumbled on the following: > > [13600.008029] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [13600.010235] Modules linked in: > [13600.010742] CPU: 30 PID: 26329 Comm: kworker/u128:2 Tainted: G W 3.11.0-next-20130906-sasha #3985 > [13600.012301] task: ffff880e54630000 ti: ffff880e52380000 task.ti: ffff880e52380000 > [13600.013553] RIP: 0010:[] [] find_vma+0x12/0x70 > [13600.014929] RSP: 0018:ffff880e52381c38 EFLAGS: 00010282 > [13600.016808] RAX: f0000040f0000040 RBX: 00007fffffffe000 RCX: ffff880e54630000 > [13600.016808] RDX: 0000000000000000 RSI: 00007fffffffe000 RDI: ffff880000000000 > [13600.016808] RBP: ffff880e52381c38 R08: 0000000000000017 R09: ffff880e52381d70 > [13600.016808] R10: ffff880e52381d70 R11: 0000000000000007 R12: ffff880e54630000 > [13600.016808] R13: ffff880000000000 R14: 000000000000000f R15: 0000000000000000 > [13600.016808] FS: 0000000000000000(0000) GS:ffff880fe3200000(0000) knlGS:0000000000000000 > [13600.016808] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [13600.016808] CR2: 0000000004a66678 CR3: 0000000e520fe000 CR4: 00000000000006e0 > [13600.016808] Stack: > [13600.016808] ffff880e52381c68 ffffffff8125a36b ffff880fb7d373c8 ffff880fb6f82238 > [13600.016808] ffff880e54630000 ffff880000000000 ffff880e52381d28 ffffffff8125622d > [13600.016808] ffff880e52381c98 ffffffff84109b7c 00000000b7d373c8 ffff880e52380010 > [13600.016808] Call Trace: > [13600.016808] [] find_extend_vma+0x2b/0x90 > [13600.016808] [] __get_user_pages+0xdd/0x630 > [13600.016808] [] ? _raw_spin_unlock_irqrestore+0x7c/0xa0 > [13600.016808] [] get_user_pages+0x52/0x60 > [13600.016808] [] get_arg_page+0x5c/0x100 > [13600.016808] [] ? get_user_arg_ptr+0x58/0x70 > [13600.016808] [] copy_strings+0x114/0x260 > [13600.016808] [] copy_strings_kernel+0x4b/0x60 > [13600.016808] [] do_execve_common+0x2f3/0x4d0 > [13600.016808] [] ? do_execve_common+0x10c/0x4d0 > [13600.016808] [] do_execve+0x37/0x40 > [13600.016808] [] ____call_usermodehelper+0x111/0x130 > [13600.016808] [] ? schedule_tail+0x30/0xb0 > [13600.016808] [] ? __call_usermodehelper+0xb0/0xb0 > [13600.016808] [] ret_from_fork+0x7c/0xb0 > [13600.016808] [] ? __call_usermodehelper+0xb0/0xb0 > [13600.016808] Code: 40 20 83 f0 01 83 e0 01 eb 09 0f 1f 80 00 00 00 00 31 c0 c9 c3 0f 1f 40 00 55 48 89 e5 66 66 66 66 > 90 48 8b 47 10 48 85 c0 74 0b <48> 39 70 08 76 05 48 3b 30 73 4d 48 8b 57 08 31 c0 48 85 d2 74 > [13600.016808] RIP [] find_vma+0x12/0x70 > [13600.016808] RSP > > The disassembly is: > > /* Check the cache first. */ > /* (Cache hit rate is typically around 35%.) */ > vma = ACCESS_ONCE(mm->mmap_cache); > 1f9: 48 8b 47 10 mov 0x10(%rdi),%rax > if (!(vma && vma->vm_end > addr && vma->vm_start <= addr)) { > 1fd: 48 85 c0 test %rax,%rax > 200: 74 0b je 20d > 202: 48 39 70 08 cmp %rsi,0x8(%rax) <--- here > 206: 76 05 jbe 20d > 208: 48 3b 30 cmp (%rax),%rsi > 20b: 73 4d jae 25a > > > Note that I've started seeing this when I started testing with 64 vcpus. mm_struct pointer (%rdi) 0xffff880000000000 looks suspicious =) > > > Thanks, > Sasha > > -- > 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/ . > Don't email: email@kvack.org -- 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/