On Sun, Jan 30, 2005 at 05:38:07PM +0200, Eran Tromer wrote: > "Some peculiarities" indeed!
I *am* practicing the art of understatement ;-) > 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. > When you > later access the corresponding virtual address, the page fault allocates > a new page at an arbitrary physical address, and you end up accessing > *that* pageframe. That sounds completely broken :-| However, is mapping /dev/mem supposed to work? I seem to recall several discussions on the subject, but no conclusions. I do recall that /dev/mem cannot work on some architectures. Were you trying this on non x86? > 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? > 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. > This bug has apparently been known for years, but never addressed. Now, > mmapping valid unreserved memory apparently entails problems with ref > counts and swapping, but if it's not implemented then the calls should > at least indicate a failure! Agreed... You know what they say about patches and happy acceptance. Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/
signature.asc
Description: Digital signature
