Re: [patch-2.3.26] /proc/kcore to access module's address range.

Tigran Aivazian (tigran@sco.COM)
Mon, 8 Nov 1999 09:59:05 +0000 (GMT)

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/