>>> Jeremy Fitzhardinge <jer...@goop.org> 01.10.09 09:43 >>> >On 09/30/09 23:40, Jan Beulich wrote: >>> Hm, _PAGE_IOMAP is x86-specific. I guess that doesn't matter in this >>> case, but it would for other drivers. Previously _PAGE_IOMAP was set in >>> vm_get_page_prot -> arch_vm_get_page_prot. Is that path no longer being >>> used? It looks like it should be. >>> >> No, that path can't be the right one: Based on what VM_* flag would you >> want to set _PAGE_IOMAP? VM_IO is definitely not the right one - I >> checked this with Nick when analyzing the crash we got reported. >> >> Further, no arch besides powerpc actually defines arch_vm_get_page_prot() >> in mainline, and in xen/master the definition indeed is (incorrectly) using >> VM_IO. > >Why, what's wrong with VM_IO? It's documented as being "Memory mapped >I/O or similar". VM_PFNMAP is another option, but that seems more >dubious. Are there places where VM_IO is being legitimately set on >normal page mappings?
This is what Nick responded on my similar question: "Hmm, good question. Unfortunately I think VM_IO was never really intended to set pte protection bits, but just protect the vma from get_user_pages (actually it is hard to know exactly what some of the vma flags bits were really intended for, but that seems to be the current reasonable use)." The most prominent reason for not deriving _PAGE_IOMAP from VM_IO is probably the fact that remap_pfn_range() sets VM_IO, but clearly can be called for local RAM pages (e.g. through mmap_kmem()). And if you grep for the uses of VM_IO, you'll find a few more examples (mostly arch specific, but anyway) that show that such an implication isn't valid at present. Jan ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
