Re: loops in get_user_pages() for VM_IO

David S. Miller
2004-11-17T06:41:52Z

On Tue, 16 Nov 2004 22:33:38 -0800
Andrew Morton <akpm@osdl.org> wrote:

> --- sles/mm/memory.c.~1~ 2004-11-12 12:30:25.000000000 +0100
> +++ sles/mm/memory.c 2004-11-16 17:58:02.752131952 +0100
> @@ -753,7 +753,7 @@ int get_user_pages(struct task_struct *t
> continue;
> }
>
> - if (!vma || (pages && (vma->vm_flags & VM_IO))
> + if (!vma || (vma->vm_flags & VM_IO)
> || !(flags & vma->vm_flags))
> return i ? : -EFAULT;
>
> which should fix up the sbuslib.c problem.

It would only becuase do_mmap_pgoff() doesn't check
the return value of make_pages_present().

> Or, better, simply advance over the VM_IO vma and onto the next one?

That would work too.

Although currently in my sparc64 tree I'm setting VM_RESERVED instead
of VM_LOCKED for I/O mappings and that solves the issue as well. It
would not, of course, solve the mlock() case you mentioned.

I think we need to set these bits consistently across the tree.
And remap_pfn_range() is a good model, so that's what I've used.
Parts of the x86 tree trigger this case too btw, for example
the pci mmap support code. In fact, all the pci mmap support
routines set VM_LOCKED, probably because they were copied over
from the first two implementations (sparc64 and i386) :-)