linux-kernel - Re: [RFC PATCH 0/8] remove vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Dec 2012 16:48:59 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	JoonSoo Kim <js1304@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King <rmk+kernel@....linux.org.uk>,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Dave Anderson <anderson@...hat.com>,
	Atsushi Kumagai <kumagai-atsushi@....nes.nec.co.jp>
Subject: Re: [RFC PATCH 0/8] remove vm_struct list management

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/