From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by kanga.kvack.org (Postfix) with ESMTP id 6A9E56B0253 for ; Fri, 25 Sep 2015 08:44:58 -0400 (EDT) Received: by qkcf65 with SMTP id f65so41363030qkc.3 for ; Fri, 25 Sep 2015 05:44:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id 13si2558674qhw.79.2015.09.25.05.44.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Sep 2015 05:44:57 -0700 (PDT) Date: Fri, 25 Sep 2015 14:41:51 +0200 From: Oleg Nesterov Subject: Re: Multiple potential races on vma->vm_flags Message-ID: <20150925124151.GA5384@redhat.com> References: <55F0D5B2.2090205@oracle.com> <20150910083605.GB9526@node.dhcp.inet.fi> <20150911103959.GA7976@node.dhcp.inet.fi> <55F8572D.8010409@oracle.com> <20150924131141.GA7623@redhat.com> <5604247A.7010303@oracle.com> <20150924172609.GA29842@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andrey Ryabinin Cc: Sasha Levin , Hugh Dickins , "Kirill A. Shutemov" , Andrey Konovalov , Rik van Riel , Andrew Morton , Dmitry Vyukov , "linux-mm@kvack.org" , LKML , Vlastimil Babka On 09/24, Andrey Ryabinin wrote: > > 2015-09-24 20:26 GMT+03:00 Oleg Nesterov : > > On 09/24, Sasha Levin wrote: > >> > >> void unmap_vmas(struct mmu_gather *tlb, > >> struct vm_area_struct *vma, unsigned long start_addr, > >> unsigned long end_addr) > >> { > >> struct mm_struct *mm = vma->vm_mm; > >> > >> mmu_notifier_invalidate_range_start(mm, start_addr, end_addr); > >> for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next) > >> unmap_single_vma(tlb, vma, start_addr, end_addr, NULL); <--- this > >> mmu_notifier_invalidate_range_end(mm, start_addr, end_addr); > >> } > > > > And I do not see any dereference at this line, > > > > I noticed, that addr2line sometimes doesn't work reliably on > compiler-instrumented code. > I've seen couple times that it points to the next line of code. Yes, I know that we can't trust it. That is why I think (at least in this particular case) function+offset would be more helpful. And we need more asm probably. > >> >> 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? > >> > >> This is indeed kasan code. 0xdffffc0000000000 is the shadow base, and you see > >> kasan trying to access shadow base + (ptr >> 3), which is why we get GFP. > > > > and thus this asm can't help, right? > > > > I think it can. > > > So how can we figure out where exactly the kernel hits NULL ? And what > > exactly it tries to dereference? > > So we tried to dereference 0x4c8. That 0x4c8 is probably offset in some struct. > The only big struct here is mm_struct. > So I think that we tried to derefernce null mm, and this asm: > > cmpq $0x0,0x4c8(%rax) > > is likely from inlined mm_has_notifiers(): > static inline int mm_has_notifiers(struct mm_struct *mm) > { > return unlikely(mm->mmu_notifier_mm); > } Looks reasonable... Thanks. I was going to say that this is impossible because the caller should have crashed if ->mm == NULL. But unmap_vmas() uses mm = vma->vm_mm, so it looks like this vma or mm->mmap was corrupted... Oleg. -- 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