lkml.org 
[lkml]   [2011]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Oops in VMA code
From
Date
On Thu, 2011-06-16 at 07:32 +0200, Alexander Graf wrote:
> On 16.06.2011, at 06:32, Linus Torvalds wrote:

> Thanks a lot for looking at it either way :).

Yeah thanks ;-) Let me see what I can dig out.

First it's a load from what looks like a valid pointer to the linear
mapping that had one byte corrupted (or more but it looks reasonably
"clean"). It's not a one bit error, there's at least 2 bad bits (the
09):

DAR: c00090026236bbc0

Alex, how much RAM do you have ? If that was just a one byte corruption,
the above would imply you have something valid between 9 and 10G. From
the look of other registers, it seems that it could be a genuine pointer
with just that stay "09" byte that landed onto it.

> The latter is the one I'm executing, while the former still has all
> the symbols. But you're right. It looks like this is simply an inlined
> function - which is why it got stripped away. Here's the disassembly
> of the whole do_unmap function. I hope it's of use despite your fading
> PPC asm skills :). Host compiler is gcc 4.3.4 from SLES11SP1.

.../...

Ok, so let's see what we can dig from here. It -looks- like:

if (!mm) goto out :

> 0xc000000000190554 <find_vma_prev>: cmpdi cr7,r3,0
> 0xc000000000190558 <find_vma_prev+4>: beq cr7,0xc0000000001907f0 <remove_vma_list+836>

rb_node = mm->mm_rb.rb_node; (rb_node in r9):

> 0xc00000000019055c <find_vma_prev+8>: ld r9,8(r3)

vma = mm->mmap (vma in r28)

> 0xc000000000190560 <find_vma_prev+12>: ld r28,0(r3)
> 0xc000000000190564 <find_vma_prev+16>: li r11,0
> 0xc000000000190568 <find_vma_prev+20>: li r26,0

while(rb_node)...

> 0xc00000000019056c <find_vma_prev+24>: cmpdi cr7,r9,0
> 0xc000000000190570 <find_vma_prev+28>: bne cr7,0xc000000000190594 <find_vma_prev+64>
> 0xc000000000190574 <find_vma_prev+32>: b 0xc0000000001905d0 <do_munmap+368>
> 0xc000000000190578 <find_vma_prev+36>: nop
> 0xc00000000019057c <find_vma_prev+40>: nop
> 0xc000000000190580 <find_vma_prev+44>: ld r9,16(r9)
> 0xc000000000190584 <find_vma_prev+48>: mr r26,r11
> 0xc000000000190588 <find_vma_prev+52>: cmpdi cr7,r9,0
> 0xc00000000019058c <find_vma_prev+56>: mr r11,r26
> 0xc000000000190590 <find_vma_prev+60>: beq cr7,0xc0000000001905c4 <find_vma_prev+112>

vma_tmp = rb_entry(rb_node, struct vm_area_struct, vm_rb);

> 0xc000000000190594 <find_vma_prev+64>: addi r26,r9,-56

if (vma_tmp->vm_end)

> 0xc000000000190598 <find_vma_prev+68>: ld r0,16(r26)

Here we go. So here vma_tmp is crap, which we got out of the rb_tree,
so it's either corruption or use after free I'd say. It could also be a
completely unrelated memory corruption of course....

If you had xmon we could have dug a little bit more to see what's
before/after etc... but like this it doesn't ring any special bell to
me.

Cheers,
Ben.




\
 
 \ /
  Last update: 2011-06-16 08:05    [W:0.069 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site