lkml.org 
[lkml]   [1999]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.3.26: high_memory and vmalloc()'d stuff (modules in particular)
the function below assumes that module_list always points to the module 
with the highest virtual address in module_info->addr. Now that I think
of it, it is not a fair assumption (though true if you never unload any
modules), so get_kcore_size should really walk through the list and pick
up the highest address.

I will adjust it, test it and send the patch later.

Regards,
Tigran.

On Sun, 7 Nov 1999, Eleonora Autore wrote:

> Hi,
>
> I have just solved this problem (and tested both with and without modules
> loaded). Here is what the size should be:
>
> unsigned long get_kcore_size(void)
> {
> unsigned long size;
>
> if (module_list == &kernel_module)
> size = ((size_t)high_memory - PAGE_OFFSET);
> else
> size = (unsigned long)module_list + module_list->size -
> PAGE_OFFSET;
> size += PAGE_SIZE; /* for the ELF header */
> return size;
> }
>
> this function should live in kernel/module.c because kernel_module is
> static to that compilation unit. So, now one can dump module's structures
> in gdb via /proc/kcore :)
>
> I will make a patch and send to you and Linus if you don't object?
>
> Regards,
> Tigran.
>
> PS. This solution wastes a few M of "holes" if one dd's the image because
> vmalloc maps addresses beyond physical memory on 8M boundary (or so) but
> this is far better than having hardcoded 2G or 4G or whatever...
>
>
> PPS. Btw, does anyobody know if it is possible to tell gdb to load symbol
> table in "ksymoops -s map" style instead of having to read it off the ELF
> binary via "file" command? That would be useful (i.e. to have module's
> symbols as well).
>
> On Sun, 7 Nov 1999, Eleonora Autore wrote:
>
> > 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    [W:0.032 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site