On Thu, 17 Apr 2003, Steven Rostedt wrote:
>
> What's the rational behind /dev/mem not being able to map unreserved RAM?
> It can't be for protecting the system, because if you have access to
> reserved RAM (kernel text) then you can modify the remap_pte_range to
> allow for mapping of ram.
>
> I have a user program for debugging kernel modules and the like, and it
> uses /dev/mem to map ram and prints it out. But unless I take out the
> check in remap_pte_range, I can't see allocated pages.
>
> I just want to know the rational behind this.
I understand your surprise and frustration.
The reason is not a very good one, it's just that we haven't
yet done the work to allow unrestrained mapping of /dev/mem.
A mapping of /dev/mem is unlike the usual mapping of a shared file.
I can't explain this at all well: might one say, when you map a file,
you are mapping the pages for the data they currently contain; but
when you map /dev/mem, you are mapping the pages for their frames?
Think about the page->count, think about how in your mapping of
/dev/mem there may be pages which belong to (currently contain
data from) mapped files (and much else besides).
When you munmap your mapping of /dev/mem, that must not free the
pages you had mapped, you don't have any hold on them at all; yet
as things stand (if you were allowed to map unReserved pages),
it would decrement page->count, free unowned pages, cause havoc.
There should be a specific VM_RESERVED flag (there is already but
it's not used in quite this way) to forbid page->count manipulations
on vmas (mappings) of /dev/mem. But that code is not in place,
so instead this rather ugly PageReserved stuff has hung around.
I did start out on eliminating PageReserved a few months ago,
but was persuaded to delay that until 2.7. When that's done,
you will be able to mmap /dev/mem properly.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:22 EST