Messages in this thread | | | Date | Mon, 8 Nov 1999 09:59:05 +0000 (GMT) | From | Tigran Aivazian <> | Subject | Re: [patch-2.3.26] /proc/kcore to access module's address range. |
| |
On Mon, 8 Nov 1999, David Howells wrote: > 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 know about those holes and I mentioned them in one of the mails, here is a quote:
> 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...
I did dd if=/proc/kcore of=kcore_with_modules.img and it worked fine including those holes, no GPF. But if what you are saying does represent real (or potential) danger, we could redesign it using a section per module.
Here is the latest version of the patch so that everyone can review it and tell us if it the heuristic used by get_kcore_size() is dangerous or not:
http://www.ocston.org/~tigran/patches/kcore-2.3.26a.patch
> 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.
Regards, Tigran.
- 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/
| |