The trick that xdos is using to get the shared writable pages uses
/proc/self/mem as a "file", so that a writable shared mapping appears to
be backed by a file. An strace shows the following calls:
mmap(0, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4017a000
mmap(0, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4027c000
open("/proc/self/mem", O_RDWR) = 7
mmap(0xa0000, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 7,
0x4017b000) = 0xa0000
mprotect(0xa0000, 65535, PROT_READ) = 0
mprotect(0xc0000, 4096, PROT_READ) = 0
mprotect(0, 0, PROT_READ|PROT_WRITE) = 0
mmap(0xb8000, 32768, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 7,
0x4017b000) = 0xb8000
mprotect(0xb8000, 32768, PROT_READ) = 0
The first mmap creates a writable area, and the mmaps for 0xa0000 and
0xb8000 create writable aliases, effectively joining shared writable
mappings with a private writable mapping. The 0xb8000 area is then set
read-only.
To fix this I think we need to mark the whole mess as unswappable. It
won't work to just test for a writable pte to a shared page -- in this
case one of the sharings is only readable. So if the readable one gets
swapped out first, the remaining mappings would still be a problem.
Anyone have any ideas for the best way to detect and handle this case?
Regards,
Bill
-
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.altern.org/andrebalsa/doc/lkml-faq.html