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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>