On 09/24, Sasha Levin wrote:
>
> On 09/24/2015 09:11 AM, Oleg Nesterov wrote:
> >
> > 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...
>
> The reason behind this message is that NULL ptr derefs when using kasan are
> manifested as GFPs. This is because in order to validate an access to a given
> memory address kasan would check (shadow_base + (mem_offset >> 3)), so in the case of
> a NULL it would try to access shadow_base + 0, which would GFP.
OK, so this just means the kernele derefs the NULL pointer,
> I'm running -next + Kirill's THP patchset.
>
> > struct mm_struct *mm = vma->vm_mm;
>
> 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,
> >> 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?
So how can we figure out where exactly the kernel hits NULL ? And what
exactly it tries to dereference?
> I hope the information above helped, please let me know if it didn't and you
> need anything else.
Thanks a lot, it does help, but I am still confused.
Looks like, "function+offset" is more useful than the line numbers,
at least we could look at mm/memory.s.
Oleg.
--
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/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>