Re: [Crash-utility] About displaying virtual memory information of exiting task
----- Original Message -----
On 12/06/2014 04:11 AM, Dave Anderson wrote:
> Interestingly enough, today I was asked to look at a vmcore in which an oops
> occurred during task exit after tsk->mm had been NULL'd out in exit_mm():
It almost matches what I am facing, when tsk->mm is set to NULL and memory
mapping is supposed to be displayed. This is a more simple implementation.
I have tried to command like vm [taskp | pid | [-M mm_struct]]. But it have
to modify a lot of thing.
By the way, I feel the code is becoming more and more complicated, maybe a
reconstruction is needed.
Well, the vm_area_dump() function is relatively stable, so let's not go crazy
here for what's essentially an "experimental" option.
>
> Of course it has its limitations. Since the page tables are being broken down in
this case,
> "vm -p" fails:
>
> crash> vm -M ffff880495120dc0 -p
> PID: 4563 TASK: ffff88049863f500 CPU: 8 COMMAND: "postgres"
> MM PGD RSS TOTAL_VM
> 0 0 0k 0k
> VMA START END FLAGS FILE
> ffff8804a085ce90 400000 f56000 8001875
> /usr/local/greenplum-db-4.3.3.1/bin/postgres
> VIRTUAL PHYSICAL
> vm: invalid kernel virtual address: 50 type: "mm_struct pgd"
> crash>
After a glance, the pgd comes from the mm of task_struct. We need a lot of work to make
it
replaced by argument of -M, I don't think it worse it right now.
Actually it doesn't take much work at all. If both tc->mm_struct and
tm->mm_struct_addr
are replaced with the supplied address:
tc->mm_struct = tm->mm_struct_addr = pc->curcmd_private;
then "vm -M ffff880495120dc0 -p" also works OK with my sample vmcore.
>
> But it does seems like a worthwhile addition.
>
> The patch doesn't check whether mm->owner or mm->mm_count are legitimate,
but I'm not
> sure whether it's even worth it? If it fails, it fails, and the help page
should just
> indicate that the command option is not guaranteed to work. Does the attached patch
work
> for you?
Similar to the core I got. And I modified the patch to add some check. At least I think
we need to make sure the address still belongs to a mm_struct object.
I suppose you could, although in all probability it's going to be stay in the
mm_struct
slab cache, and worst case, have been re-used by another task.
Dave