Messages in this thread | | | Subject | Re: [patch-2.3.26] /proc/kcore to access module's address range. | Date | Mon, 08 Nov 1999 09:31:34 +0000 | From | David Howells <> |
| |
Tigran Aivazian wrote: > 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).
And also: > 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.
There might be a better way of introducing modules, but I'm not sure it's worth it. I think there's a problem with the way you suggested - it leaves holes in the accessible memory range that are valid as far as the ELF core-dump is concerned, but will cause a GPF in the kernel if you try and access them. A better way would be to define each module's address space as a separate section in the ELF core dump, but this makes the task more complex.
I'm not sure that the problem actually exists. It depends on whether the module space begins immediately after "high_memory", and also what happens to holes that remain after modules are unloaded.
David
- 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/
| |