----- Original Message -----
> On 12/02/2014 10:00 PM, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> >> Hello Dave,
> >>
> >> I'd like to discuss about the following feature with you and get some
> >> advise.
> >>
> >> vm command is used to display virtual memory information of a task. But if the
> >> task is exiting(according to crash, 'tsk->flags& PF_EXITING' is true), vm will
> >> set mm to 0 in get_task_mem_usage(). But the mm may be not freed yet, the mm and
> >> its related virtual information is helpful when debuging a exiting task.
> >
> > But it may have been freed, and in the case of CONFIG_SLUB, the mm_struct.mmap member
> > would be overwritten as a free slab object link pointer, making it useless. Or it
> > could have been freed-and-reused.
> >
> >>
> >> I was considering to ignore the IS_EXITING(task) in get_task_mem_usage() and
> >> if tsk->mm is set to NULL but the mm is not freed(see the following case), then we
> >> can specify the mm manually.
> >>
> >> CASE(the code is from kernel):
> >> <cut>
> >> exit_mm()
> >> {
> >> ...
> >> tsk->mm = NULL; --> dump after this, and before mmput() freeing mm
> >> ...
> >> mmput(mm);
> >> }
> >> <cut>
> >>
> >> But I guess it is not a good design to you. So I reconsidered it. What about specifying
> >> mm to vm just like task's pid or address. Then vm can retrieve virtual memory information
> >> from specified mm directly. And get the owner task from mm->owner.
> >
>
> The thought above is to make specifying mm to be a more common use, just like specifying
> pid or taskp. Users may get mm from back trace, then he doesn't need to find its owner(task)
> first. So it is just another way to display virtual memory information of a task.
>
> For the special cases, the task->mm is exiting but mm is not freed (or we can judge it by
> checking whether mm->mm_users is 0), the original vm command is not available to display
> virtual memory information. But I think there are people care about virtual memory even
> when the task is exiting. Since the mm is still there, why doesn't crash show them?
>
> > That might work, at least if:
> >
> > (1) the mm_struct has not been freed (SLUB),
> > (2) the mm_struct has not been freed-and-reused, and
> > (3) the kernel is configured with CONFIG_MEMCG and mm->owner points to
> > the exiting task.
> >
> > But how would a typical user of this option know what the mm_struct address is?
>
> It is true there are people who don't know what mm_struct is. But there are still some people
> who know what mm is, especially for those who tries to debug exiting tasks.
You misunderstood my question -- how would a typical user determine the *address* of the mm_struct?
Have you actually tried this as an experiment? At a minimum, the option would have
to reject an mm_struct that has a mm->mm_users of 0.
In any case, feel free to post a patch and we'll see what it looks like.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
