On Wed, 05 Jul 2006 20:40:36 -0700 (PDT), David Miller wrote: >> I.e., X did a simple PROT_READ|PROT_WRITE MAP_SHARED mmap() of >> something PCI-related, presumably the ATI card. The protection >> bits passed into io_remap_pfn_range() are 0x80...0788, while >> pg_iobits are 0x80...0f8a. Current kernels obey the prot bits, >> which, if I read things correctly, means that _PAGE_W_4U and >> _PAGE_MODIFIED_4U don't get set any more. >> >> I guess something else in the kernel should have set those >> bits before they got to io_remap_pfn_range()? > >The problem is with X, it should not be doing a MAP_SHARED >mmap() of the framebuffer device. It should be using >MAP_PRIVATE instead. > >The kernel is trying to provide copy-on-write semantics for >the mapping, which doesn't make any sense for device registers. >That's why the kernel isn't setting the writable or modified >bits in the protection bitmask. Now I'm confused. That COW behaviour would be consistent with MAP_PRIVATE, not MAP_SHARED which is what X did use. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
