On Thu, Oct 01, 2009 at 09:31:19AM -0700, Jeremy Fitzhardinge wrote: > On 10/01/09 01:41, Jan Beulich wrote: > >> 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)." > > > VM_PFNMAP seems more specifically about preventing get_user_pages (ie, > no struct page), (though I guess that could have changed with > _PAGE_SPECIAL ptes). And there's the ever-mysterious VM_RESERVED. Does > that mean it
Well, yes basically these VM flags need a good cleanup. What should be done is like GFP flags where we define specific bits which direct the core mm to do a _particular_ thing (eg. don't get_user_pages, or this points to IO memory, etc). and then define combinations of them which are useful to drivers. I think Jan's point is simply that drivers _currently_ are in a bit of a mess here so the trivial approach to using VM_IO is not going to work without some fixups. PFNMAP may be used when we _do_ have struct pages but don't want to touch them, and also IO mappings can have pfn_valid true if the memory model has allocated a memory map for those pages. So I don't think they quite fit. Also drivers don't always want to allow get_user_pages even if they are working on normal memory (actually the default should be to _disallow_ it and a bit should be set to allow it, because you have to be somewhat aware of what the races and page reference lifetimes are with get_user_pages). > > 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()). > > mmap_kmem looks pretty broken anyway. All the CONFIG_STRICT_DEVMEM > checks make sure the pages being mapped are *not* regular pages, and > will end up failing all /dev/kmem mappings as a result. So I think in > that case I think it gets set as an accidental erroneous side-effect. > > > 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. > > > > Pointers? The overwhelmingly common use is on mappings of hardware > devices, and most of the tests of the bit explicitly reference IO as the > reason they're testing it. Why would you set it if the mapping weren't > for IO anyway? There are other ways to prevent, for example, core > dumping it, or having it participate in normal memory management, or > preventing get_user_pages, or whatever. > > The use of remap_pfn_range() is a slightly different matter, but it also > looks like it is only used on device memory too (aside from the kmem > thing mentioned above). But I'm not sure if it is defined to be only > used on IO(-like) memory regions... Last time I audited most of the drivers due to the expanding-mremap security hole, there are definitely a large number of them that just seemed to randomly set VM_IO and/or VM_RESERVED. Probably due to the fact that they aren't well defined to start with. ------------------------------------------------------------------------------ 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
