Re: [RFC PATCH 0/8] remove vm_struct list management

[Vivek Goyal <vgoyal@redhat.com>]

On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote:

[..]
> > So without knowing details of both the data structures, I think if vmlist
> > is going away, then user space tools should be able to traverse vmap_area_root
> > rb tree. I am assuming it is sorted using ->addr field and we should be
> > able to get vmalloc area start from there. It will just be a matter of
> > exporting right fields to user space (instead of vmlist).
> 
> There is address sorted list of vmap_area, vmap_area_list.
> So we can use it for traversing vmalloc areas if it is necessary.
> But, as I mentioned before, kexec write *just* address of vmlist and
> offset of vm_struct's address field.
> It imply that they don't traverse vmlist,
> because they didn't write vm_struct's next field which is needed for traversing.
> Without vm_struct's next field, they have no method for traversing.
> So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is
> a safe way to maintain a compatibility of userspace tool. :)

Actually the design of "makedumpfile" and "crash" tool is that they know
about kernel data structures and they adopt to changes. So for major
changes they keep track of kernel version numbers and if access the
data structures accordingly.

Currently we access first element of vmlist to determine start of vmalloc
address. True we don't have to traverse the list.

But as you mentioned we should be able to get same information by
traversing to left most element of vmap_area_list rb tree. So I think
instead of trying to retain vmlist first element just for backward
compatibility, I will rather prefer get rid of that code completely
from kernel and let user space tool traverse rbtree. Just export
minimum needed info for traversal in user space.

Thanks
Vivek