Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1232097
| From | Oleg Nesterov <oleg@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Multiple potential races on vma->vm_flags |
| Date | 2015-09-24 15:20 +0200 |
| Message-ID | <qceBl-48v-25@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <q75yI-4zn-51@gated-at.bofh.it> <q7a5k-2Ey-17@gated-at.bofh.it> <q7u41-7zp-7@gated-at.bofh.it> <q7HNE-2kQ-7@gated-at.bofh.it> <q92n1-3er-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 09/15, Sasha Levin wrote: > > I've modified my tests to stress the exit path of processes with many vmas, > and hit the following NULL ptr deref (not sure if it's related to the original issue): I am shy to ask. Looks like I am the only stupid one who needs more info... > [1181047.935563] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN Well, I know absolutely nothing about kasan, to the point I can't even unserstand where does this message come from. grep didn't help. But this doesn't matter... > [1181047.937223] Modules linked in: > [1181047.937772] CPU: 4 PID: 21912 Comm: trinity-c341 Not tainted 4.3.0-rc1-next-20150914-sasha-00043-geddd763-dirty #2554 > [1181047.939387] task: ffff8804195c8000 ti: ffff880433f00000 task.ti: ffff880433f00000 > [1181047.940533] RIP: unmap_vmas (mm/memory.c:1337) I do not know which tree/branch do you use. In Linus's tree mm/memory.c:1337 is struct mm_struct *mm = vma->vm_mm; but this doesn't match the asm below, > 0: 08 80 3c 02 00 0f or %al,0xf00023c(%rax) > 6: 85 22 test %esp,(%rdx) > 8: 01 00 add %eax,(%rax) > a: 00 48 8b add %cl,-0x75(%rax) > d: 43 rex.XB > e: 40 rex > f: 48 8d b8 c8 04 00 00 lea 0x4c8(%rax),%rdi > 16: 48 89 45 d0 mov %rax,-0x30(%rbp) > 1a: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax > 21: fc ff df > 24: 48 89 fa mov %rdi,%rdx > 27: 48 c1 ea 03 shr $0x3,%rdx > 2b:* 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction > 2f: 0f 85 ee 00 00 00 jne 0x123 > 35: 48 8b 45 d0 mov -0x30(%rbp),%rax > 39: 48 83 b8 c8 04 00 00 cmpq $0x0,0x4c8(%rax) > 40: 00 And I do not see anything similar in "objdump -d". So could you at least show mm/memory.c:1337 in your tree? Hmm. movabs $0xdffffc0000000000,%rax above looks suspicious, this looks like kasan_mem_to_shadow(). So perhaps this code was generated by kasan? (I can't check, my gcc is very old). Or what? Any chance you can tell us where exactly we hit NULL-deref in unmap_vmas? Oleg. -- 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/
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: Multiple potential races on vma->vm_flags Oleg Nesterov <oleg@redhat.com> - 2015-09-24 15:20 +0200
Re: Multiple potential races on vma->vm_flags Sasha Levin <sasha.levin@oracle.com> - 2015-09-24 18:30 +0200
Re: Multiple potential races on vma->vm_flags Oleg Nesterov <oleg@redhat.com> - 2015-09-24 19:30 +0200
Re: Multiple potential races on vma->vm_flags Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2015-09-24 21:00 +0200
Re: Multiple potential races on vma->vm_flags Sasha Levin <sasha.levin@oracle.com> - 2015-09-24 21:10 +0200
Re: Multiple potential races on vma->vm_flags Oleg Nesterov <oleg@redhat.com> - 2015-09-25 14:50 +0200
csiph-web