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
| ||
|
Message-ID: <20121207145909.GA4928@redhat.com> Date: Fri, 7 Dec 2012 09:59:09 -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 Fri, Dec 07, 2012 at 10:16:55PM +0900, JoonSoo Kim wrote: > 2012/12/7 Andrew Morton <akpm@...ux-foundation.org>: > > On Fri, 7 Dec 2012 01:09:27 +0900 > > Joonsoo Kim <js1304@...il.com> wrote: > > > >> I'm not sure that "7/8: makes vmlist only for kexec" is fine. > >> Because it is related to userspace program. > >> As far as I know, makedumpfile use kexec's output information and it only > >> need first address of vmalloc layer. So my implementation reflect this > >> fact, but I'm not sure. And now, I don't fully test this patchset. > >> Basic operation work well, but I don't test kexec. So I send this > >> patchset with 'RFC'. > > > > Yes, this is irritating. Perhaps Vivek or one of the other kexec > > people could take a look at this please - if would obviously be much > > better if we can avoid merging [patch 7/8] at all. > > I'm not sure, but I almost sure that [patch 7/8] have no problem. > In kexec.c, they write an address of vmlist and offset of vm_struct's > address field. > It imply that user for this information doesn't have any other > information about vm_struct, > and they can't use other field of vm_struct. They can use *only* address field. > So, remaining just one vm_struct for vmlist which represent first area > of vmalloc layer > may be safe. I browsed through makedumpfile source quickly. So yes it does look like that we look at first vmlist element ->addr field to figure out where vmalloc area is starting. Can we get the same information from this rb-tree of vmap_area? Is ->va_start field communication same information as vmlist was communicating? What's the difference between vmap_area_root and vmlist. 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). CCing Atsushi Kumagai and Dave Anderson. Atsushi-san is the one who maintains makedumpfile. Dave Anderson maintains "crash" and looks like it already has the capability to traverse through vmap_area_root rb-tree. So please let us know if left most element of vmap_area_root rb-tree will give us start of vmalloc area or not? 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/
Powered by blists - more mailing lists