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.
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.
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.
--
Regards
Qiao Nuohan