lkml.org 
[lkml]   [1999]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.3.26: high_memory and vmalloc()'d stuff (modules in particular)
Hello David and the World,

I am trying to enhance your ELF /proc/kcore read routine to deal with the
kernel virtual addresses corresponding to dynamically loaded modules.

I managed to successfully dump data structures in gdb vmlinux /proc/kcore
by making the size very large (260M). Obviously this is not a perfect
solution but is tied to this particular machine. Besides, I want to be
able to dd if=/proc/kcore of=kcore.img and dumping 260M of stuff most of
which is garbage is not very elegant.

So, the question (to everyone) is:

How do we determine the value similar to high_memory but one that covers
modules as well? I.e. currently size is calculated as:

size = ((size_t)high_memory - PAGE_OFFSET) + PAGE_SIZE;

so, if high_memory=0xc4000000 and module's data structure is at
0xc4815a6c we can't dump it in gdb because dhdr->p_memsz/p_filesz are set
accordingly in the ELF core header.
Any ideas anyone? Ideally, there would be (or is there already?!)
something called highvm_memory that would be used instead of high_memory
and would make /proc/kcore's size lazy-dynamically-adjustable on the fly
as new modules are loaded. I could hack vmalloc()/vfree() to do that but
perhaps it is already done, so I am asking you (in the meantime I will go
and try to find a way of determining it).

Regards,
Tigran.

PS. I don't submit the patch even though it works for me because this
"solution" is obviously only a temporary workaround - I want a proper
"highvm_memory" or something...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site