If you use remap_page_range (e.g., via /dev/mem) to mmap a physical address that's valid and unreserved (i.e., all of "normal" memory), it fails silently: the PTE is allocated but left marked as not present (see mm/memory.c/remap_pte_range).
So far it sounds correct (for the general case) - mapping should not
cause the page to be faulted in. It should only create the appropriate
vma with the appropriate nopage function so that the right memory will
be faulted in when it is accessed.
But in this case there shouldn't be any fault -- just pointing the PTE to a given pageframe.
However, is mapping /dev/mem supposed to work? I seem to recall
several discussions on the subject, but no conclusions.
It certainly gives a impression of being *supposed* to work: it implements mmap(), and even works in some cases. So any way you look at it, it's a bug.
Were you trying thison non x86?
Yes. Though the brokenness applies to any machine that supports mmaping /dev/mem.
To recap: you say "I want to access physical address X"; the kernel says "no problem, here it is" and maps you to a different physical
address.
Which kernel version? does it happen with 2.6-latest?
Tested and source-inspected on 2.6.9.
I wasted several days because of this bug (first on getting bad data, then on tracking it down). It didn't help much that mmap() on /dev/map is broken, but lseek()+read() on /dev/mem work fine, so if you look at /dev/mem using dd or hexdump it looks like the data is there.
/dev/mem is special, I'm afraid.
How is that an excuse for inconsistency between two semantically equivalent ways to access the same resource? If anything, it's a reason to explicitly fail when asked for a nonsensical or unsupported operations.
Eran
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
