On Thu, Oct 01, 2009 at 09:41:39AM +0100, Jan Beulich wrote: > >>> 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.
It would be very nice to break them into "no get_user_pages" and "points to IO space" as generic flags. I'm not the best person to ask about this though, I don't know the arch or driver code so well. For generic code there would be no problems (except running out of flag space)... ------------------------------------------------------------------------------ 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
