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/