[lkml]   [2000]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PROBLEM: Is remap_page_range() working properly?
Thanx for the answer.

> You can only remap reserved or I/O space
> Read drivers/sound a bit - it has code that allocates, reserves and remaps
> memory

Oh, now I see why I found so many references to
remap_page_range() in sound cards code. But there is still
something that seems odd to me:

1) Why using the remap_page_range() to perform the mmap() of
/dev/mem ?
In this way, as I happened to find out, you can mmap() only the
reserved pages of physical memory, when theoretically /dev/mem
should grant you access to the whole physical memory in the
system; and performing a read() or write() system call on /dev/mem
affects even non-reserved pages (I tested the read(), and the code
of write() seems to me to behave in the same way).
Is there any theoretical reason that suggests that mmap() should
not be able to read pages accessible with read() and write()?

2) Wouldn't it be a good idea to change the comment about the
remap_page_range()? It states:

> maps a range of physical memory into the requested pages. the
> old mappings are removed. any references to nonexistent pages
> results in null mappings (currently treated as "copy-on-access")

There is no reference to the fact that only the reserved pages in
physical memory can be mapped. No mention of I/O addresses is
present, as well. And no mention that references to non-reserved
physical pages will result in null mappings.

just my 2c, of course.

- Andrea Santoro
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.118 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site