Re: loops in get_user_pages() for VM_IO

[David S. Miller]

On Tue, 16 Nov 2004 22:33:38 -0800
Andrew Morton <akpm@xxxxxxxx> 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) :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/